Challenging challenge: client-side password hashing and server-side password verification

Question

We have a website where users need to log in to access privileged information. Obviously we are using SSL, but I also want to avoid plaintext passwords from accidently ending up in server logs, or wandering eyes of administrators. Therefore, I want to implement client-side hashing using Javascript.

Furthermore, I want to avoid revealing pairs of users with identical passwords, thus use a user-specific salt. Lastly, I would like to add a random challenge (aka nonce) into the mix to ensure an eavesdropper* can not use the final hash as the new "password". I will make an additional roundtrip to the webserver to obtain the salt and challenge before starting the password hashing. *) Yes, we are using SSL, but as a defense in depth I would like to make the implementation as solid as possible.

Especially the challenge is challenging. The only feasible implementation I know of, is first calculating the final password hash (using bcrypt, scrypt or PBKDF2) and then do one additional sha256_hmac round using the challenge. On the server-side we fetch the password hash from the database and perform the same additional sha256_hmac and compare the result.

However, the above would imply that the full password hash calculation must be done client-side in Javascript, because hashing in the challenge should always be the last step. On a legacy(?) iPhone 3G, only 6 bcrypt rounds, or 5000 PBKDF2-SHA256 rounds can be done within 2 seconds which is the maximum delay we can tolerate.

Question #1: Am I correct that nowadays bcrypt should be at least 12 rounds, and PBKDF2-SHA256 at least 5000 rounds? So I should choose the 5000 rounds of PBKDF2-SHA256?

Question #2: Do there exist challenge-response mechanisms that can operate earlier in the process (e.g. on a once hashed password), so I can leave the bcrypt/PBKDF2 hardening to the webserver?

Question #3: Assuming no such challenge-response mechanism exists, is it better to abandon my challenge-response requirement and only apply a user-specific salt client-side and do thorough hardening server side? Would that result in an overall stronger system than using a challenge-response mechanism and less rounds?

EDIT: To summarize the long trail of comments below about the security of client-side hashing in general: the general opinion seems to be that the added complexity is not worth it and it is better to put the effort in auditing the server-side code and limiting server-side access for untrusted staff.

Answer 1

I think you're wasting your time and adding needless complexity. I don't think the reasons you give are sufficient to warrant this kind of client-side password hashing mechanism.

Instead, I suggest keeping it simple. Send the password over a SSL-encrypted link. When it comes to security, simple is good. Needless complexity is the enemy of security, because it introduces the opportunity for bugs and mistakes.

Save your energy for other security tasks that will address more realistic threats. There's a limited amount of time and energy and budget one can spend on improving security; best to spend it on the places that will yield the greatest bang for the buck (the greatest improvement in security, given the investment). I think you'll find there are other ways you could spend your hardening your system that will improve security more.

If you're worried about whether the server-side code is handling the password appropriately, then review that code carefully: it should be contained to within a very small chunk of code. This should take care of risks like, e.g., the server logging cleartext passwords: you just read every line of code that's involved with password checking or that reads the password, make sure the first thing it does is to hash the password appropriately, and make sure that all it does is check the password for validity and return true or false. If your system is well-designed, this should be pretty straightforward to verify through code review. If the code isn't well-designed, maybe now would be a good time to fix that.

Answer 2

If you have not done so already, you may want to look into SRP. It should meet all of your requirements, if you want a challenge/response type system.

http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Answer 3

I would be wary of any home brewed protocol. I would also be wary of any client-side hashing based authentication protocol. Your best bet is to study NTLM Authentication and the LARGE NUMBER of attacks against this protocol. Such as the NTLM weak nonce vulnerability.

(SRP isn't bad, SRP-TLS looks pretty cool.)

Answer 4

1. No, you're still too small. OWASP Password Storage Cheat Sheet recommends 64,000 PBKDF2 iterations in 2012 and doubling them every 2 years (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet).

2. See the other answers above.

3. You do have the option of doing some hashing client-side (say, 2,000 PBKDF2_SHA-1 rounds), and then once the result of that gets to the server, run it through another large set of hashing (say, 300,000 rounds of PBKDF2_SHA-512), and compare that final value.

Your database stores only the final double-PBKDF2 value.

Your web log files and/or possibly weak SSL sessions use the intermediate single-PBKDF2 value. While that intermediate value is certainly much, much weaker than the final value, it's still quite a lot stronger than cleartext.

Note that you also need to check passwords users propose when changing their password/selecting a new passwords against a normal cracking dictionary with some rules (lowercase both to eliminate case games, add numbers from 1 to 1000 after the word, add dates after a word, basic 1337 speak translations, etc.) to prevent the "strong" password "P@$$w0rd" (upper case, lower case, symbols, and numbers - 8 characters long, it must be really strong!) from showing up.