4

I'm experimenting with PBKDF2 for my passwords right now, and it dawned on me that if I were to ever upgrade to a faster machine in the future, I would want to increase the number of PBKDF2 iterations. However, this would invalidate all the current passwords that I have stored. One idea I've seen was to store the PBKDF2 settings along with the password (similar to how you store the salt) such as the iteration count and the PRF used (SHA-256, SHA-512) at the time of the hash creation. It sounds like a good idea in terms of backwards compatibility, but I wanted to know if there are any drawbacks to doing this. Any insight into this would be appreciated.

Huy T
  • 1,273
  • 1
  • 11
  • 21
  • I would strongly recommend looking at bcrypt using `crypt()`. It stores all of this information for you already, and is stronger than pbkdf2... – ircmaxell Aug 27 '14 at 14:35

1 Answers1

5

You are definitely taking the right direction here. Many systems store just the salt but where is the rest of the parameters required to perform PBKDF2? Hardcoded! And hardcoding parameters of cryptographic functions is almost never a good idea.

Only drawback I see is that when you store all the parameters your database will probably take a little more space but your future upgrades will be much easier and straightforward.

BTW RFC 2898 defines structure called PBKDF2-params which was designed as a data holder for all the public parameters of PBKDF2 algorithm. Use it at least as an inspiration so you won't forget any important parameter.

jariq
  • 11,681
  • 3
  • 33
  • 52
  • 1
    Thanks! Space isn't as a big deal to me as security and scalability. I took a look at the PBKDF2-params, and I pretty much will be storing everything in there alongside the password except for key-length. I don't see any scenario where we would need to change the length of the hash we'll be storing. Thanks again. – Huy T Aug 20 '14 at 06:16