From 389-users:

I had a bit of a read, and I'm not sure about this.

Like, I can see why you want to do this, because it makes migration
from these possible.

However, the crypt module is bad, and all those schemes are "weak" for
password storage now.

So, lets say there is a compromise here on this feature.

What if we made it so DS could bind a user with the hash set to this
scheme, but you could never make a new password with this scheme. IE you
would leave:

nsslapd-storagescheme: {SSHA512,PBKDF2_SHA256}

But your user has:

uid=migrated_account,ou=People,dc=....
...
userPassword: {CRYPT}$6$<salt>$hash

So you could bind to this account, but then on next password change the
userPassword would become:

userPassword: {PBKDF2_SHA256}........

What do you think of this solution?

It will not be hard to add this feature, and we should be competitive with other LDAP vendors. I think this is something we should seriously consider for 1.3.7 (maybe even 1.3.6 - upstream only).

I’ll agree with you that the CRYPT algorithm is bad; but last I checked, salted SHA-256 and -512 are still on the “OK” list. The default hashing algorithm in RHEL 7 / CentOS 7 is (salted) SHA-512.

On the practical side, if password change policies are set such that users will need to change their passwords every 30 days - or even 90 days - that’s not going to be enough time to migrate off an entire production environment from one authentication mechanism to another. The intent is good in forcing migration to a more secure scheme; but approaching the problem in that way could make migration more, rather than less, difficult.

I do really like the idea of specifying it via "nsslapd-storagescheme” or similar, rather than as a parameter to the plugin, as that ties in well with the rest of the password change policy settings. I can see where for some environments, that would significantly aid in migration. Isolate the groups that can’t migrate immediately, focus efforts on the groups that can migrate, and then clean up the remainder as it becomes possible.

Hey @plaidhat

The problem with using "nsslapd-storagescheme", is that checks only the content between the {} braces in the encoded result. IE, {SSHA512}......., we only extract SSHA512, then we pass off to the SSHA512 plugin to do the rest of the work.

So really, we still need to have {CRYPT} plugin do the work, but what I'm suggesting is that if code in crypt.c actually just does an if condition on the stored hash to then work out and apply the various crypt algos you suggest from these docs. This would allow a bind to still succeed.

For migration that I suggested, what I meant was:

• dump your db from sunds (db2ldif).
• import ldif to 389-ds/rhds

At this point, 389-ds and your users have {CRYPT}<sha*> passwords right on objects in 389ds. They can still bind, everything is okay. But, what we do is have your nsslapd-storagescheme set to one of SSHA512 or PBKDF2_SHA256, and when they next change password on 389ds, it'll change the hash algo for the dn. This way you get migration, and a forward supported hash storage path. Does that make sense?

I'm still against the crypt module being able to create new hashes for users though, because I think this module would be for migration purposes only.

Now, as for password hash algos: Anything that is SHA is considered bad now by security experts. SHA is a verification algo, not a key derivation function. As a result, it can be hardware accelerated and attacker quickly by an attacker who gets your hash dumps (even with salt).

Today is Directory Server we default to SSHA512, only because we need to maintain replication with a 1.2.x series server. In the future, we will change this default to PBKDF2_SHA256, when we have the ability to say "hey no more 1.2.x replication to version X.".

I hope that explains more about the process and thoughts going on related to this feature.

So I added 3 new schemes: CRYPT-MD5, CRYPT-SHA256, and CRYPT-SHA512

Won't these all write with the schemes in their names though? IE:

{CRYPT_SHA256}$....

I thought the idea was that we would have them all as:

{CRYPT}...
{CRYPT}$1$....
{CRYPT}$5$.....

Also, have a look at the dirsrvtests/suites/password I think: you can add these to the password suite tests by adding the algo to the list there I think.

Won't these all write with the schemes in their names though? IE:
{CRYPT_SHA256}$....

Correct

I thought the idea was that we would have them all as:
{CRYPT}...
{CRYPT}$1$....
{CRYPT}$5$.....

Hmm, I didn't know that was the plan, but that will work. However, since there are new storage schemes I would expect, as a end user, to see the configured scheme when I look at the password. I see no harm in leaving it as is.

Also, have a look at the dirsrvtests/suites/password I think: you can add these to the password suite tests by adding the algo to the list there I think.

I'll check this out, thanks!

I thought the idea was that we would have them all as:
{CRYPT}...
{CRYPT}$1$....
{CRYPT}$5$.....

Hmm, I didn't know that was the plan, but that will work. However, since there are new storage schemes I would expect, as a end user, to see the configured scheme when I look at the password. I see no harm in leaving it as is.

I think we should ask @plaidhat for a sample from his current setup, or we need to look at the sun/oracle as a reference to be sure.

I thought the idea was that we would have them all as:
{CRYPT}...
{CRYPT}$1$....
{CRYPT}$5$.....
Hmm, I didn't know that was the plan, but that will work. However, since there are new storage schemes I would expect, as a end user, to see the configured scheme when I look at the password. I see no harm in leaving it as is.

I think we should ask @plaidhat for a sample from his current setup, or we need to look at the sun/oracle as a reference to be sure.

@plaidhat already told me offline he was cool with this, but I'll let him confirm here.

Something else to keep in mind, which is what led me in this direction, is when using subtree policies you can set different polices per subtree. So while unlikely, it is possible you could use different crypt schemes per user/subtree. So again we would want to know which scheme is being used. Of course if you know the crypt internals you would could decipher the format to known which scheme is being used, but that's asking too much of Admins IMO.

Ahhh makes sense. So long as @plaidhat is okay with it, and it works for his usecase that is okay.

What happens today if the userPassword field is se to:

{CRYPT}$5$ .....

I would think that would work wouldn't it?

@plaidhat Contacted me and said this was okay. Ack from me!

Revised patch

I will push this after we branch for 1.3.7

d95c07b..a771800 master -> master

Fixed CI test.

Also, turns out we do use {crypt} in userpassword for all the CRYPT storage types (I thought I changed that but I didn't). Well it's pushed upstream so we'll just leave it as is. So @plaidhat you don't need to change anything in your scripts.

Works for me, either way. Thanks!

@mreynolds What do we use for the storage type then? IE what does a userPassword attr look like with this?

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2284

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.