3

People often recommend PBKDF2 over using hash functions directly, but typically they compare PBKDF2 to a single unsalted hash. What advatages are there to using PBKDF2 over multiple iterations of a cryptographic function with the password and salt appended to the previous hash at each iteration?

Pseudo-code:

password="mypass0rd";
salt=random();
hash = password;
for (int i=0;i<1000;i++){
    hash = sha512(hash+password+salt);
}
Improve this question
  • 4
    Basically, because PBKDF is a standard for doing this, whereas you're "implementing your own" security solution. Almost always A Bad Idea TM. – deed02392 Mar 21 '14 at 19:19
  • A more valid question would be why is PBKDF2 better than BCrypt or SCrypt, and the only good answer there is that PBKDF2 can use cryptographic hash functions listed in your nation's regulations (in the U.S., that's FIPS 140-2, and in Europe, that's Nessie, and perhaps some other possible attacks against SCrypt. – Anti-weakpasswords Mar 22 '14 at 2:28
5
  1. Don't roll your own crypto. Generally, if you are directly calling (as opposed to specifying the name of) some crypto primitive (SHA-512, AES, etc), then you are violating this rule. If you think crypto implementation bugs are not hard to avoid, I suggest you give Matasano's crypto challenges a try.
  2. Fewer lines of your code. This means fewer chances of you messing something up. It also means cleaner, more maintainable code.
  3. Configurable iteration counts. Sure you could change the iteration variable in your code, but what about all the hashes you already have lying around? A library implementing PBKDF2 will have a built-in way to store and retrieve the iteration count for each hash.
  4. Avoid RNG bugs. Your code makes a call to random(), but most languages' built-in PRNGs are not crypto-safe. Get a library that does salt generation for you, and you avoid the extra hassle and possible bugs.
  5. Portability. Need to upgrade or change your backend? You can probably just copy (database export/import) your users' records and old hashes into the new framework. Otherwise you have to rewrite your custom hashing algorithm for the new framework, running into implementation differences:
    • Is the output of sha512 raw bytes or hex?
    • What character encoding did you use for passwords?
    • Is salt a string or a number, and how does it get converted into bytes for the input to sha512?
Improve this answer
1

One important difference between your construction and PBKDF2 is that PBKDF2 uses a pseudo-random function (prf), typically HMAC, instead of a hash directly. SHA1 and SHA2 are not prfs, and so certain security proofs don't apply to them.

One theoretical problem with your construction is that you can hit internal collisions or short chains. Because your salt and password stays in each iteration, if you ever produce the same hash twice as you go through, then you will end up in a cycle of hashes. (PBKDF2 suffers from a variant of this as well, but it does illustrate the kind of thing to look out for.)

So you would do better with your loop looking like 

hash = hmac-sha512(i + salt + password, hash)

but for all of the reasons that others have pointed out, you are still better off using PBKDF2, warts and all, instead of rolling your own.

PBKDF2 alternatives

scrypt is superior to PBKDF2 for almost all situations. But it is harder to learn to use correctly. PBKDF2 is superior to bcrypt.

It also should be noted that PBKDF2 was designed for key derivation, not for password hashing. So it has some features and characteristics that aren't really what you need. (And it has a bug in that component that only matters for key derivation, and only is very unusual circumstances).

As much as I'm criticizing PBKDF2, I still think it is better to use it than to roll your own. The particular problems with it are not something that you will run into with password hashing.

A successor to PBKDF2/scrypt/bcrypt

You may wish to follow the developments of the Password Hashing Competition. This is an attempt to find a suitable successor to PBKDF2, scrypt, bcrypt for password hashing. But for the moment, just use scrypt if available to you or PBKDF2.

Improve this answer
  • Could you explain why you think that PBKDF2 is superior to BCrypt? – martinstoeckli Mar 22 '14 at 20:36
  • There really are no compelling reasons to prefer PBKDF2 over bcrypt and this is almost a matter of taste. (scrypt, however, does have real advantages over both). PBKDF2 is more modular in that (a) you can choose your PRF, and (b) it can also be asked to produce different output sizes. (Though is can screw that up, so maybe that isn't a virtue.) – Jeffrey Goldberg Apr 24 '14 at 1:25
  • This is a great answer. Can you post some references regarding PBKDF2 suffering from a variant of the weakness you mentioned? As for producing different output sizes, that tends to be very bad when being used for passwords. Bcrypt is often considered superior because it is also memory hard (even if only a little, at 4 KiB). The main issue with bcrypt is the fact that the input size is limited, though you can overcome that trivially with a single cryptographic hash function. – forest Feb 10 '18 at 23:26
  • @forest, I've actually been bitten by the PBKDF problem I describe. A (now legacy) data format used by 1Password gave the attacker a 1 bit advantage. See blog.agilebits.com/2013/04/16/… – Jeffrey Goldberg Feb 16 '18 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.