Re: Questions regarding PDBKD2 iteration count status and possible optimization
by William Brown
> 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
4 weeks, 1 day
Questions regarding PDBKD2 iteration count status and possible optimization
by Tobias Ernstberger
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?
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?
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"?
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?
Kind regards,
Tobias Ernstberger
4 weeks, 1 day
Directory Administrators vs. Password Administrators
by tdarby＠arizona.edu
I see tn the docs that you can make a Password Administrators group, like so:
dn: cn=config
changetype: modify
replace: passwordAdminDN
passwordAdminDN: cn=Passwd Admins,ou=groups,dc=example,dc=com
I'm curious though, what privileges does a Directory Administrator have over and above one of these Password Administrators.
1 month, 1 week
Determining max CSN of running server
by William Faulk
I'm having another replication problem where changes made on a particular server are not being replicated outward at all. Right now, I'm trying to determine what's going on during the replication process.
(Caveat: I'm still running an old version of 389ds: v1.3.10. In particular, the dsconf utility does not exist.)
My understanding is that when a server receives a change from a client, it wraps it up as a CSN and starts a replication session with its peers, during which it sends a message that states the greatest CSN that it originated. First off, is that a correct understanding?
If so, how can I determine what CSN a particular server is telling its replication peers during those sessions? I have a feeling that this server is, for some reason, sending an inaccurate number.
In the cn=replica,cn=...,cn=mapping tree,cn=config tree, there are entries for each of the servers topology peers, and they contain nsds50ruv attributes that seem to be the RUVs that that server has received from those peers, right? But the nsds50ruv attribute also exists directly in the cn=replica if you explicitly ask for it. Is it possible that this is the server's own RUV?
Can I rely on the nsds50ruv attributes on this server's peers' cn=replica nsds50ruv attribute values to be an accurate reflection of what this server is sending as its CSN in replication sessions?
Any other way to see what's going on in a replication session? (I'm even trying to decrypt a network capture, but I'm not having any luck with that yet.)
In particular, I see the max CSN for this server in all of these RUVs less than CSNs recorded in the server's own log files.
--
William Faulk
1 month, 3 weeks
