|
PBKDF2 is a very common way to achieve the "work factor" I mentioned in my response, yes.
I agree that if the number of iterations is properly set, it should be secure for most purposes. But still, there are alternatives to it, namely bcrypt and scrypt, because custom-built hardware can reduce the cost of bruteforcing. You can check the details on the wikipedia section about these alternatives: https://en.wikipedia.org/wiki/PBKDF2#Alternatives_to_PBKDF2
Still, while using the work factor is indeed a must (and I agree that PBKDF2 should be sufficient), it is not enough.
If you don't use a unique salt, an attacker can immediately identify whether there are any passwords that are reused for several users.
The last link on my previous post, which describes the Adobe case, is a great illustration of how bad it is if there's no unique salt in each entry. Even if you can't break the passwords, just knowing that some of them are the same is something you should avoid (and the salt makes it easy to achieve). Things like the password hint are also very sensitive, and those will require reversible encryption.
Finally, the HMAC aspect is also something to consider.
While it won't help if the entire system is compromised, it will make it impossible to do any kind of attack provided only the database is stolen, but not the application code that is generating and validating the hashes.
In Adobe's case, they were using reversible encryption (3DES) instead of all the hashing techniques we're discussing, but AFAIK the key wasn't stolen, or at least made public. Without such key - or the HMAC one - you might "play crosswords" with identical hashes for different users, but you won't be able to brute force anything.
|