Questions about BCrypt and PBKDF2

Question

I would ask you some questions about users' password storage in a login system.

1. What algorithm do you suggest me to use? bcrypt or PBKDF2?

I was looking for a way to implement them client-side and i thought this way:

The client computes 10.000 iteractions of user's password with PBKDF2 and username (or email) as SALT and the server will store in the DB the salted SHA-512 digest of the PBKDF2 result.

1. Is it a good way?
2. Is client-side key stretching good in general? Does it have some disadvantages compared to the server-side implementation?
3. Is there a better way to implement PBKDF2 client-side?

4. And what about bcrypt?

5. If I use bcrypt server-side, what's the best way to add a pepper?

6. Adding pepper has some disadvantage?

Answer 1

What's your motivation for slow-hashing on the client-side?

• It may well be slower than if performed server side (if you're referring to a browser-based application, and the hashing is done with javascript, then it will certainly be slower, even more so if it's a mobile device)
• it doesn't provide any extra security, the credential(s) (password, hash of the password, salt derived from password which will be used for hashing the password, whatever...) will still need to be transmitted to the server - there's no way to avoid that

Keep it simple - you're much less likely to introduce some sort of vulnerability into your system. The following protocol is pretty standard:

• send the client's username/password to the server over TLS/SSL (it's worth the effort, really)
• slow-hash the client's password with either Scrypt (preferable), or PBKDF2-SHA256 (at least 100'000 iterations) and a user-specific salt (stored in the DB with the hash)
• for each login attempt, compare the output of the above with the hash you have stored in the DB

Note: Bcrypt is fine, some people fetishize it, others prefer PBKDF2 because it's more 'standard' (and it's output length is configurable). Scrypt is the state-of-the-art, although it's less widely used, and can be more complicated to implement.

EDIT

After further consideration, and better understanding exactly what you're asking (I think), I'm going to say yes: what you're proposing is fine, provided certain conditions are met. The issue that @StephenTouset pointed out is valid, and has to be avoided. However, if I understand your question correctly, then you're already mitigating that weakness. Consider the following:

1. Client slow-hashes password with PBKDF2 or Scrypt (use of email address or username as salt is questionable - email addresses change and usernames could be used in dictionary attacks). This initial slow-hashing mitigates dictionary attacks, and offloads the heavy work from the server to the client

2. Client submits the output of the slow-hash (256 bits) to the server (over TLS/SSL), where it is then hashed once with SHA-256 (no salt necessary) and compared with the hash stored in the database.

Should the database be compromised, an attacker would still need to brute-force the hash of a 256-bit value (the client-side slow-hash output) to verify a correct guess at the password, pretty much rendering the hashes stored in the database useless to an attacker.

I think the theory is fine. In practise, I think it's a bit messy and maybe unwarranted (your comment mentioned up to 1000 login attempts per second, are you really anticipating up to 86 million logins per day??). Only you can decide whether you can justify it.

Answer 2

To answer the "pepper" part of the question:

• Generate a cryptographically random secret key 256 bits in length.

• Any time a user submits a password:

  1. compute hmac = HMAC-SHA-256(key, password)
  2. submit hmac to the slow-hash instead of the password

Answer 3

Bcrypt is slow, since it uses Blowfish (and insecure, due to the fact that it has 64-bit block, though it could be extended to 128-bit block [which I will call Blow128]) I would recommend PBKDF2. Taking the SHA-512 hash of the PBKDF2 result is bad, because chaining two hash functions (even though PBKDF2 is not a hash function) For the other questions, I would consider editing the question so I could answer it fully.

Edit:
I recommend Bcrypt, even though PBKDF2 is another choice. Still SHA-512 of PBKDF2 would be bad, because $H_{1}(H_{2}(X))$ is bad (despite the fact that PBKDF2 is not a hash function). Besides, what I thought is slow hashing was nothing. The main goal of hash functions are they be fast but secure. So basically I was against the hash functions. By slow hashing you might mean moderate slow hashing, because you don't want a digital signature algorithm to take a week, to process a 1 MB PDF.