> On 29 Mar 2024, at 00:53, Tobias Ernstberger <tobias.ernstberger@xxxxxxxxxx> wrote: > > Hello, > > I have several questions regarding PBKDF2 as password storage scheme, maybe > someone can help? > > 1) Is it correct, that in the latest version the number of iterations for > new hashes is not configurable, but determined dynamically based on > calculations? Generally yes. This is because we still have to meet a level of performance for binds-per-second on large deployments. As a result we have a trade - Do we enforce longer iterations at the expense that we may only have a low number of binds per second? Or do we lower the number of iterations to allow more binds? For example, we could aim for a time factor of 1 second, but this means on a system with 8 cpus then only 8 binds can progress per second. If we aim for 1/4 of a second, then we can now proceed with 32 per second. > 2) If yes: I think for compliance reasons it would be a good idea to add a > configurable "minimum iterations" variable. This might slow down > authentication but could help to enforce a minimum security level if > required. Any comments? There already is a "compiled in" minimum based on the NIST-800-63B minimum of 10,000 rounds. The problem with configuration though is that more configuration knobs sometimes creates problems for users - Once a user sets that value, if we ever increase it in future then they won't get the new values we ship with. If we let people have that config and they set it too low, they weaken their security. If they set it too high they lower their bind throughput. I'd prefer we do the "right thing" by default than add more configuration. > 3) Am I right, that if the current calculation results in higher "iterations > number" than used before (e.g., at the time of a last password-change of a > user), the hash remains unchanged until new passwort-change? The "Password > Upgrade on Bind" > (https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html) does not > apply for "more iterations"? Within 389-ds, yes. There is currently not an effective way in the upgrade on bind code to measure the relative strength of the existing password. > 4) If yes: This could be a valuable improvement as the general idea of > PBKDF2 is to increase iteration count over time while hardware resources are > growing. Any comments? Yes, that would be. However, I'd only do so on the rust versions of the hashers: https://github.com/389ds/389-ds-base/tree/main/src/plugins/pwdchan/src The reason for this is that when I initially wrote the PKBDF2 code, it was in C and had to use the NSS cryptographic library. There is a flaw in NSS's PBKDF2 implementation that makes it 4 times slower than openSSL's. The NSS developers did not want to fix this, even though it effectively weakens the KDF strength of passwords. However, more recently we added support for importing the password hashes from OpenLDAP. In this process we added hashers in Rust that used OpenSSL. The NSS/C version only remains to support existing installs. For now this version hardcodes 10_000 rounds (https://github.com/389ds/389-ds-base/blob/main/src/plugins/pwdchan/src/lib.rs#L114) but this version is much easier to extend and improve. This is generally why we advise the use of the PBKDF2-SHA256 pwhash algorithm (note it's a '-' not '_'. For historical reasons the C version uses the '_' (underscore) and the rust one the '-' (hypen)). Hope that gives you some more context. -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia -- _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
