On 29 Mar 2024, at 00:53, Tobias Ernstberger
<tobias.ernstberger(a)de.ibm.com> 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/li...) 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