I've read various opinions about whether Bcrypt or PDBKF2 is a better key derivation hashing method. The answer seems to depend on a lot of complicated factors that are not easy to analyze. Would using both of them (presumably in a serial way one before the other) accrue the benefits of both and thus achieve an optimally secure solution?
Add a comment
|
1 Answer
Mixing the two functions would not really help. Bcrypt and PBKDF2 both have a configurable cost: you are supposed to set the number of iterations at the maximum value which is still tolerable in your situation, given the available hardware and the environmental constraints (e.g. average user patience). If you want to use both function together, then they must share the same CPU budget; in other words, you would have to decrease the number of iterations compared to what you would use in either function alone.
So you do not get something stronger that way; instead, you get a security level which is an average of what you would have got with Bcrypt alone, or with PBKDF2 alone.
Combining two hash functions or similar functions together is good to avoid a catastrophic failure, if one turns out to be broken; but, assuming that both Bcrypt and PBKDF2 are strong, and the question is mostly about performance (both bcrypt and PBKDF2 are about making exhaustive search slower, so this is all about performance). For optimal slowness, combining bcrypt and PBKDF2 is not a good idea.
For the choice between bcrypt and PBKDF2, see this previous answer. To sum things up:
Bcrypt is better if your hardware is PC-like (i.e. has several kilobytes of RAM with fast access). It is harder for the attacker to optimize exhaustive search with a GPU, if bcrypt is used, compared to PBKDF2.
PBKDF2 has NIST's blessing (it is Approved, with a big 'A'). NIST says nothing about bcrypt.
Bcrypt outputs 192 bits, which is fine for a password verification token, or if you just need 192 bits (or less) of password-derived key material. On the other hand, PBKDF2 is a key derivation function and can produce as many bits as you wish, which is good if you need more than 192 bits of key material.
answered Feb 9, 2012 at 20:52
-
Why constrain the CPU budget, and not use the same X iterations of each? If the desire is to protect from a broken hash, does it matter what order they are applied? Commented Feb 10, 2012 at 3:28
-
Protect from a broken hash: if all are working ok, brute-force would spend x times in the first hash and y time in the second hash, with a total of x+y. If any is fully compromised, the attacker will spend the total of 1+y or x+1, and the order didn't matter. Commented Feb 10, 2012 at 11:39
-
2@makerofthings7: we do not constrain the CPU budget; it is constrained "by itself". When you verify a password, you want to be done with it within the next, say, 5 seconds -- the user will not wait longer. We cannot crank up the iteration count as high as we want, because the system must remain usable. Commented Feb 10, 2012 at 12:55
-
Even though Bcrypt doesn't have NIST's blessing, do you think it's widely used, including by large organizations with sensitive information, for example banks, online retailers, etc.? Does using it meet PCI Compliance requirements?– DanCommented Feb 10, 2012 at 16:54
-
@Dan As far as I know, PCI doesn't specify actual technology, especially Encryption specifications. The legal cases I've seen support what's technically feasible, not technically ideal or perfect. I'm sure either one meets PCI requirements Commented Feb 10, 2012 at 17:29