Gold Standard for password hashing

Question

I've developing a web application that will be dealing with highly sensitive information and I want to ensure the hashing of passwords is gold standard. Ideally I'd go for per-user salted SHA512 using PBKDF2 to carry out multiple iterations of the algorithm but as I'm developing in asp.net, there's no built-in .net SHA512 version for PBKDF2 - I'm limited to SHA1 (i.e. Rfc2898DeriveBytes).

My question is really, bearing in mind I'm developing in .net and am securing sensitive information, what's the best way to hash user passwords?

Should I stick with .net's SHA1 PBKDF2 implementation?
Should I use a custom implementation of PBKDF2 to incorporate SHA512?
Should I be preferring bcrypt or scrypt despite the fact that they're not widely standards accredited (e.g. NIST)?

http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough — damiankolasa, Dec 12 '12 at 13:49
IMHO if a PBKDF2 implementation won't let you control a critical component like the hashing function, then it's probably not worth using. The fact that it uses SHA1 makes it worthless. — Sammitch, Dec 13 '12 at 23:47
@Sammitch As Polynomial says, SHA1 is fine for this purpose, though hash function agility is indeed a good thing. — nealmcb, Sep 21 '14 at 00:30

Polynomial · Accepted Answer · 2012-12-12T19:47:13.397

11

I'd go for the in-built Rfc2898DeriveBytes, with a high number of iterations - the higher the number the better, but I'd recommend 5000 as an absolute minimum. SHA1 is considered broken for some uses, but not in the way it's used in PBKDF2, and probably won't ever be within the lifetime of your product.

Implementing your own PBKDF2 with SHA512 shouldn't be hard though. In fact, Microsoft provide a reference implementation that uses SHA256.

edited Dec 12 '12 at 19:47

answered Dec 12 '12 at 13:57

Polynomial

132,208
43
298
379

2

Quoting the [NIST recommendations for PBKDF2](http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf), "A minimum iteration count of 1,000 is recommended. For especially critical keys, or for very powerful systems or systems where user-perceived performance is not critical, an iteration count of 10,000,000 may be appropriate.". As you are dealing with sensitive information you'd probably want to go with an even higher iteration count than 5000. This of course can be a usability/security tradeoff problem. – Henning Klevjer Dec 12 '12 at 14:35
2

@HenningKlevjer Agreed, I mean 5000 as an _absolute_ minimum. The best way to select your iteration count is to benchmark and calculate what the absolute maximum value you can get away with is. – Polynomial Dec 12 '12 at 14:43
I wouldn't say "Microsoft provides...", it's just a third party article in MSDN Magazine. Your "SHA1 is not yet broken" sentence isn't written clearly either, since SHA1 is broken, just not as it's used in PBKDF2. I'd reformulate it to make that clearer. – CodesInChaos Dec 12 '12 at 17:25
@CodesInChaos I'll edit, but the Microsoft thing is close enough. – Polynomial Dec 12 '12 at 19:46

score 10 · Answer 2 · edited Mar 17 '17 at 10:46

Bcrypt is marginally "better" than PBKDF2. However, PBKDF2 is already quite fine: used properly, it ceases to be the weakest point in your system.

Remember that the point of the iterations in PBKDF2 is to make the password hashing slow for the attacker. Unfortunately, it makes it slow for you, too. You thus need to avoid making it unduly slow for you. In particular, consider SHA-512: SHA-512 uses a lot of 64-bit arithmetic operations. The attacker can buy PC which are good at 64-bit operations (recent enough x86 CPU have a 64-bit mode, and older processors could use SSE2 opcodes). Your server, on the other hand, could be a bit more limited: if your server runs in 32-bit mode, then SHA-512 will be quite slow for you (because you use .NET and in .NET you do not fiddle with SSE2 opcodes), giving the attacker a computing advantage (by a factor of about 6).

Using the system-provided PBKDF2 implementation maximizes the chances that you will not have such an artificial slowdown (in particular it could use a native-code implementation of SHA-1). The known shortcomings of SHA-1 do not impact its security when used in PBKDF2.

If you do anything "by yourself" then you have to understand these performance issues with all their fine details; and, if anything goes wrong, you will probably get the blame.

KeithS · Answer 3 · 2012-12-19T15:59:20.370

Personally, I would go ahead and use BCrypt. The algorithm may not be NIST-listed, but it's been around long enough (13 years now, and the Blowfish cipher itself almost 20) that I'd trust it. By comparison, MD5 was shown to be vulnerable a mere 5 years after its introduction and was considered completely broken in 18 years.

The only known attack on the Blowfish cipher in its 20 years is a known-plaintext attack, requiring an exponential number of known input messages and resulting ciphertexts (2^8n+1 where n is the number of rounds of the Feistel cipher; for standard 16-round Blowfish that's 2^129) to derive the key. For BCrypt, this same attack is infeasible; first, there's only ever one plaintext that is "valid" for BCrypt (the ASCII string "OrpheanBeholderScryDoubt"), and second, the key that would be reverse-engineered by feeding in other plaintexts is the result of the exponentially-complex key derivation function that obfuscates the password in the first place. There was a vulnerability shown in one C implementation of it for Unix systems, that broke the algorithm if it were fed a password containing non-base-ASCII characters; as a result, new algorithms that do not have the vulnerability should be prefaced with the BCrypt variant "$2y$" (though most still use the older "$2a$" which is ambiguous; the algorithm that generated the hash could be secure, but maybe not).

Now, while I prefer BCrypt, PBKDF2's no slouch. Although SHA-1 is considered vulnerable because of its constant, relatively low complexity, the estimated cost to break a single hash by renting enough CPU from a cloud provider to execute that attack would be about $2.77 million. In PBKDF2, SHA-1 is used as an HMAC, meaning SHA-1 hashing is performed at least twice per iteration of the derivation function. With 5,000 iterations and a key length of 320 bits (requiring two sets of 5,000 iterations, one for each half of the derived key), any vulnerability in breaking a single hash is offset by the fact that you'd have to reverse-engineer twenty thousand of them (adding complexity on the order of 2^14.3, making the complete attack something like 2^175).

Multiplying the $2.7 million cost to crack one SHA hash by the increased complexity gives you... a price tag of about $55.4 billion to break one PBKDF2 hash "the long way" (knowing nothing about the input password). Anyone who has that kind of scratch, and wants your secret, will find a cheaper way.

I should mention it here again, the 2^61 collision attack on SHA-1 (and even the 2^80 birthday attack) is irrelevant to password hashing.. — Thomas, Dec 19 '12 at 15:39
Edited; the vulnerability here is SHA's relative speed compared to newer KDF-style hashes (like PBKDF2). — KeithS, Dec 19 '12 at 15:59

score 1 · Answer 4 · answered May 16 '15 at 13:36

If you care about the security of someone's password, you should move away from PBDKF2, and at least to BCrypt. Look at the state of the art in cracking hardware.

For BCrypt cracking in hardware, look at High-Speed Implementation of bcrypt Password Search using Special-Purpose Hardware.

| Algorithm  | hashes/sec | hashes/sec/Watt |
|------------|------------|-----------------|
| BCrypt(12) |      410.4 |           20.52 |
| BCrypt(5)  |   51,437   |        2,572    |

They create a custom ASIC (the "Virtex-7"), that is 10x faster than a CPU (and 30x faster than a video card), and uses 6% of the power of either.

That is state of the art of cracking BCrypt password. Now compare that with PBKDF2. I have a 2.5W USB stick that calculates 350M hashes per second. You can try 1,000 iterations, 5,000 iterations, and even it iOS standard 10,000 iterations:

| Algorithm   | hashes/sec | hashes/sec/Watt |
|-------------|------------|-----------------|
| BCrypt(12)  |      410.4 |           20.52 |
| BCrypt(5)   |   51,437   |        2,572    |
| PBKDF2(10k) |   35,000   |       14,000    |
| PBKDF2(5k)  |   70,000   |       28,000    |
| PBKDF2(1k)  |  350,000   |      140,000    |

Each of the 2.5W USB sticks costs about $8 (i have 14 of them connected to my server).

Virtex-7 custom ASIC: $3,495
USB stick: $8

Using the costs

| Algorithm   | hashes/sec | hashes/sec/Watt | hashes/sec/$ |
|-------------|------------|-----------------|--------------|
| BCrypt(12)  |      410.4 |           20.52 |       0.1174 |
| BCrypt(5)   |   51,437   |        2,572    |      14.717  |
| PBKDF2(10k) |   35,000   |       14,000    |   4,375      |
| PBKDF2(5k)  |   70,000   |       28,000    |   8,750      |
| PBKDF2(1k)  |  350,000   |      140,000    |  43,750      |

score 0 · Answer 5 · answered Dec 12 '12 at 14:04

As far as i know, all mentioned key-derivation functions are ok to use. You could even use BCrypt.net, because it is the algorithm that decides over the weakness/strongness of the hash-values and not the implementation of the library. As long as the library calculates the correct values, you should be fine.

Gold Standard for password hashing

5 Answers5