IDM currently supports PBKDF2, BCrypt, and SCrypt secure password hashing algorithms. However, these are currently using hard-coded secure parameter values that have a significant performance impact. It's likely that customers will choose less secure algorithms if the performance impact is too large. It would therefore be useful to allow customers to tune the cost parameters for these algorithms for the needs of their environment.
For example, IDM's PBKDF2 implementation defaults to PBKDF2-SHA3-256 with 20,000 iterations which takes a significant fraction of a second to run. After performance testing DS has settled on PBKDF2-HMAC-SHA256 with just 10 iterations by default, to closely match existing benchmark results, while documenting to increase the iterations in the security guide.
It would also be good to be able to specify a different core hash algorithm for PBKDF2 as SHA3 is fast in hardware and (relatively) slow in software, which gives an advantage to crackers as they are more likely to be using custom hardware/FPGAs.
- The number of iterations or cost factor should be a tunable configuration parameter. This is the number of iterations for PBKDF2, the cost factor for BCrypt, and the N parameter for Scrypt (the p and r parameters are not usually changed).
- The hash algorithm for use with PBKDF2 should be configurable.
- When the cost/iterations is changed it takes effect the next time a user changes their password. This implies that the configuration options should be stored with each hashed password.