Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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);
}
share|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 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 at 2:28
add comment

2 Answers

  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?
share|improve this answer
add comment

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.

share|improve this answer
    
Could you explain why you think that PBKDF2 is superior to BCrypt? –  martinstoeckli Mar 22 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 at 1:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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