Why use PBKDF2 over multiple iterations of a another cryptographic hash function?

Question

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);
}

Answer 1

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?

Answer 2

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.