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)?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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      |

Answer 5

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.