Can I dynamically calculate an appropriate number of iterations for PBKDF2 based on the system time, rather than using a fixed value? Could you choose the number of PBKDF2 iterations based upon the system time?

I've heard a few people recommend that the number of iterations for PBKDF2 should be doubled every two years (starting with the recommended 1000 iterations in the year 2000 when PKCS #5 was released).

Theoretically at least, you could determine the ideal iterations through an equation based upon the current time. Perhaps something like:

year = &lt;current time in years&gt;
exponent = (year - 2000) / 2
iterations = 1000 x (2 ^ exponent)


Which would give a value of about 115,196 iterations at the time of writing.

Assuming that:


The system clock can be trusted.
The number of iterations is stored with the hash, so that hash verification is still possible.
Safeguards are in place to stop the system attempting to hash with a ludicrous number of iterations.
You continue to monitor the actual time taken to hash passwords on your specific hardware.
You regularly upgrade hardware to keep up with the increasing performance requirements.
You choose an appropriate underlying hash algorithm.


Would such a system be safe and practical?
Of course you can - but as to whether or not it's a practical or advisable idea, I don't think so.  It's not really prudent to implement crypto systems/protocols and assume that they'll be fine in 10 years.

Cryptography is a dynamic field that changes rapidly; algorithms get broken, hardware improves, governments try to undermine the field, and attacks only ever become more sophisticated.  The only way to ensure the security of your system is to stay abreast of what's happening in the crypto/security world, and to adjust your system/protocol accordingly.  For example, despite the recommendation of doubling PBKDF2 rounds periodically, many people in the community now recommend a memory-hard PBKDF like Scrypt instead, making PBKDF2 more or less redundant (although not quite, as it's used internally in Scrypt, and in systems where memory is not available).

Your proposal does have an upside though: a vast majority of security/crypto protocols get implemented and forgotten about.  Look at the linked-in fiasco for example - at the time of designing the system, the architect may have (however erroneously) thought that a saltless sha1 hash of the user's password would be sufficient security.  These days, the idea of a prominent website doing this is unthinkable (hopefully).  So in this sense, your proposal does at least attempt to stay up-to-date, which in lieu of a static system, is better than nothing.  However, I think that continuous scrutiny and a more "hands on" approach is preferable.