I'm curious if anyone has any advice or points of reference when it comes to determining how many iterations is 'good enough' when using PBKDF2 (specifically with SHA-256). Certainly, 'good enough' is subjective and hard to define, varies by application & risk profile, and what's 'good enough' today is likely not 'good enough' tomorrow...
But the question remains, what does the industry currently think 'good enough' is? What reference points are available for comparison?
Some references I've located:
- Sept 2000 - 1000+ rounds recommended (source: RFC 2898)
- Feb 2005 - AES in Kerberos 5 'defaults' to 4096 rounds of SHA-1. (source: RFC 3962)
- Sept 2010 - ElcomSoft claims iOS 3.x uses 2,000 iterations, iOS 4.x uses 10,000 iterations, shows BlackBerry uses 1 (exact hash algorithm is not stated) (source: ElcomSoft)
- May 2011 - LastPass uses 100,000 iterations of SHA-256 (source: LastPass)
- Jun 2015 - StableBit uses 200,000 iterations of SHA-512 (source: StableBit CloudDrive Nuts & Bolts)
- Aug 2015 - CloudBerry uses 1,000 iterations of SHA-1 (source: CloudBerry Lab Security Consideration (pdf))
I'd appreciate any additional references or feedback about how you determined how many iterations was 'good enough' for your application.
As additional background, I'm considering PBKDF2-SHA256 as the method used to hash user passwords for storage for a security conscious web site. My planned PBKDF2 salt is: a per-user random salt (stored in the clear with each user record) XOR'ed with a global salt. The objective is to increase the cost of brute forcing passwords and to avoid revealing pairs of users with identical passwords.
References:
- RFC 2898: PKCS #5: Password-Based Cryptography Specification v2.0
- RFC 3962: Advanced Encryption Standard (AES) Encryption for Kerberos 5
- PBKDF2: Password Based Key Derivation Function v2
