3

Using the Express.js framework and crypto to hash a password with pbkdf2 I read that the default algorithm is HMAC-SHA1 but i dont understand why it hasnt been upgraded to one of the other families or SHA. 

crypto.pbkdf2(password, salt, iterations, keylen, callback)

Is the keylen that we provide the variation of the the SHA we want? like SHA-256,512 etc?

Also how does HMAC change the output?

And lastly is it strong enough when SHA1 is broken?

Sorry if i am mixing things up.

czioutas
  • 1,032
  • 2
  • 11
  • 37

2 Answers2

1

Is the keylen that we provide the variation of the the SHA we want? like SHA-256,512 etc?

As you state you're hashing a password in particular, @CodesInChaos is right - keylen (i.e. the length of the output from PBKDF2) would be at most the number of bits of your HMAC's native hash function.

  • For SHA-1, that's 160 bits (20 bytes)
  • For SHA-256, that's 256 bits (32 bytes), etc.
  • The reason for this is that if you ask for a longer hash (keylen) than the hash function supports, the first native length is identical, so an attacker only needs to attack bits. This is the problem 1Password found and fixed when the Hashcat team found it.

Example as a proof:

Here's 22 bytes worth of PBKDF2-HMAC-SHA-1 - that's one native hash size + 2 more bytes (taking a total of 8192 iterations! - the first 4096 iterations generate the first 20 bytes, then we do another 4096 iterations for the set after that!):

  • pbkdf2 sha1 "password" "salt" 4096 22
    • 4b007901b765489abead49d926f721d065a429c12e46

And here's just getting the first 20 bytes of PBKDF2-HMAC-SHA-1 - i.e. exactly one native hash output size (taking a total of 4096 iterations)

  • pbkdf2 sha1 "password" "salt" 4096 20
    • 4b007901b765489abead49d926f721d065a429c1

Even if you store 22 bytes of PBKDF2-HMAC-SHA-1, an attacker only needs to compute 20 bytes... which takes about half the time, as to get bytes 21 and 22, another entire set of HMAC values is calculated and then only 2 bytes are kept.

  • Yes, you're correct; 21 bytes takes twice the time 20 does for PBKDF2-HMAC-SHA-1, and 40 bytes takes just as long as 21 bytes in practical terms. 41 bytes, however, takes three times as long as 20 bytes, since 41/20 is between 2 and 3, exclusive.

Also how does HMAC change the output?

HMAC RFC2104 is a way of keying hash functions, particularly those with weaknesses when you simply concatenate key and text together. HMAC-SHA-1 is SHA-1 used in an HMAC; HMAC-SHA-512 is SHA-512 used in an HMAC.

And lastly is it strong enough when SHA1 is broken?

If you have enough iterations (upper tens of thousands to lower hundreds of thousands or more in 2014) then it should be all right. PBKDF2-HMAC-SHA-512 in particular has an advantage that it does much worse on current graphics cards (i.e. many attackers) than it does on current CPU's (i.e. most defenders).

For the gold standard, see the answer @ThomasPornin gave in Is SHA-1 secure for password storage?, a tiny part of which is "The known attacks on MD4, MD5 and SHA-1 are about collisions, which do not impact preimage resistance. It has been shown that MD4 has a few weaknesses which can be (only theoretically) exploited when trying to break HMAC/MD4, but this does not apply to your problem. The 2106 second preimage attack in the paper by Kesley and Schneier is a generic trade-off which applies only to very long inputs (260 bytes; that's a million terabytes -- notice how 106+60 exceeds 160; that's where you see that the trade-off has nothing magic in it)."

Community
  • 1
  • 1
Anti-weakpasswords
  • 2,604
  • 20
  • 25
0

SHA-1 is broken, but it does not mean its unsafe to use; SHA-256 (SHA-2) is more or less for future proofing and long term substitute. Broken only means faster than bruteforce, but no necesarily feasible or practical possible (yet).

See also this answer: https://crypto.stackexchange.com/questions/3690/no-sha-1-collision-yet-sha1-is-broken

A function getting broken often only means that we should start migrating to other, stronger functions, and not that there is practical danger yet. Attacks only get stronger, so it's a good idea to consider alternatives once the first cracks begin to appear.

Community
  • 1
  • 1
Patrick
  • 33,984
  • 10
  • 106
  • 126
  • but i dont see any reason to use a broken hash function and a bit wierd that it is still the default when SHA has moved almost to SHA3. I dont suppose you have any more answers to the rest of the qs? But thnx a lot! – czioutas Jan 20 '14 at 09:25
  • AFAIK SHA-3 is not even standardized yet. I justed wanted to make the point that often half-knowledge and hypes lead to wrong decisions (e.g I heard from a firm they don't want to use TLS beacause there are (theoretical) attacks on it. Im not a security expert but as far as i remember SHA-1 is totally safe to use and secure so there is no need (yet and in the possible near future) to use other algorithms. Usually the security concept does not break and points like this. – Patrick Jan 20 '14 at 09:34
  • 2
    HMAC-SHA1 is not broken even though SHA1 is. Even HMAC-MD5 is perfectly functional. This is because HMAC is substantially less affected by collisions than the hash functions. HMAC only requires preimage resistance from the hash function, and both MD5 and SHA1 are completely preimage resistant. – ntoskrnl Jan 20 '14 at 11:30
  • @for3st +1 to ntoskrnl's remark, and no, SHA-3 is [*not* standardized at the time of writing](http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html). That said, the algorithm has been choosen and *presumably* SHA-3 will use the number of rounds etc. in the Keccak paper (after some criticism towards NIST). But standardized it aint...yet. You should *definitively* not use SHA-1 for new protocols, with the possible exception of key derivation functions. And PBKDF2 is of course a key derivation function. – Maarten Bodewes Jan 20 '14 at 23:54