[OPENIDM-14229] Allow tuning PBKDF2/Bcrypt/Scrypt parameters Created: 20/Dec/19  Updated: 18/Jun/20  Resolved: 16/Jan/20

Status: Resolved
Project: OpenIDM
Component/s: Module - Authentication
Affects Version/s: 7.0.0
Fix Version/s: 7.0.0

Type: Improvement Priority: Major
Reporter: Neil Madden Assignee: Travis Haagen
Resolution: Fixed Votes: 0
Labels: CLARK
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is documented by OPENIDM-14277 Update the documentation on hashing c... Closed
relates to OPENIDM-7467 Add support for additional hash types... Closed
is related to OPENIDM-14985 Can’t configure kbaInfo to use bcrypt... Open
is related to OPENIDM-13293 Request for IDM to allow for hashed p... Resolved
Target Version/s:
QA Assignee: Brayden Roth-White
Story Points: 3
Sprint: 2020.01 - IDM
Support Ticket IDs:


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.

Acceptance Criteria

  1. 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).
  2. The hash algorithm for use with PBKDF2 should be configurable.
  3. 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.

Comment by Neil Madden [ 20/Dec/19 ]

I think just doing PBKDF2 would be sufficient.

Comment by Travis Haagen [ 16/Jan/20 ]


Generated at Wed Oct 21 09:59:55 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.