Are there any slow Javascript hashing algorithms like bcrypt?

Question

I'm not talking about server-side node.js.

I want to use a slow hashing algorithm for a key on the client-side of my site. I have found implementations of SHA-256 which seem to be reliable. I also found this question which lead to the OP creating his own library.

However, I'm not sure if I should just do multiple rounds of SHA hashing or trust some of that code since I'm not a security expert and it doesn't seem to have a large following only being "stared" by 36 people.

What is the best choice in this case? I (basically) cannot change methods once I choose something.

I want a slow hashing (not encryption) algorithm and I would rather it produced a short string. For example, a slow 60 char bcrypt vs fast 70 char SHA-256.

Answer 1

There are currently three key-derivation functions widely considered to be secure against brute force cracking attempts. Key-derivation functions are slightly different from regular hashing algorithms in that they are designed to be slow, even in the face of modern GPU-based computation.

I'll list them in order of theoretical security:

• PBKDF2 is designed by RSA, based on SHA, and is the algorithm recommended by NIST. There's a couple implementations that you could use in a browser.

  Note to Node users: Node's crypto module has a built-in PBKDF2 function. Use that.

• bcrypt, based on Blowfish, is slightly more secure than PBKDF2. It has been relatively well-tested and verified secure, but does not have a stamp of approval from any standards bodies, if that's a consideration for you. There's a generic JS implementation here.

  Note to Node users: Use node.bcrypt, which performs the computationally expensive stuff on a separate thread.

• Finally, scrypt is far and away the most theoretically secure (slowest) KDF. Unfortunately, the algorithm is very new, so it has not been validated by rigorous study and testing by the cryptographic community. It is, however, on track to become a IETF standard.

  Because the algorithm is so new, it is hard to find implementations. I could only find this half-baked one. While the security benefits are very promising, I would not recommend scrypt until both the algorithm itself and its implementations are verified secure.

How do these three actually compare? The scrypt paper has a comparison:

Realistically, even PBKDF2 makes it cost-prohibitive for anyone but a government to crack a single 8-character password.

Answer 2

You can always ignore the last 10 characters of the fast SHA-256. Or xor the first 10 characters to be included.

SHA has a variable number of rounds. Two rounds of SHA should be reversible somewhat. I have a vague idea that 20 rounds is considered "safe". 30 rounds should be "highly secure" and 50 rounds doesn't practically improve at all the security.

SHA is designed to be secure -- not by hoping that the cracker has a slow enough machine -- but by mathematical proof. If and when the number of irreversible bits in each round is increased and permuted to the 256 bit hash code, there will never be enough computer power to try all possible sequences that generate that particular hash code. Not even enough energy in the universe to wrap a 256-bit counter.

Unless the string that produces the hash is very small or written on a post-it on somebody's monitor.