userPassword changed to PBKDF2_SHA256 after bind

[Francesc Guasch]

Hello.

After upgrade to 389 release 1.4 I experienced an odd behaviour.

If I add a new user, then I bind with that user. The userPassword
attribute gets changed to {PBKDF2_SHA256}.

These are the steps I follow to reproduce it:

1- add a new entry with MD5 password, it is like this: {MD5}N7...
2- connect to LDAP and bind with the user just created
3- connect with admin and retrieve the password, it is {PBKDF2_SHA256}

I may have been doing something wrong but my code worked on previous
releases of 389-ds.

I extracted code from my project to build a full test on it. I uploaded
it to gist:

https://gist.github.com/frankiejol/9e099ba828c8cbdff361783c177643da

This is 1.4.1.6-4. So I have seen there is 1.4.2 release but
I haven't been able to build it. It gets stuck on make lib389

ModuleNotFoundError: No module named 'packaging'
make: *** [Makefile:14474: lib389] Error 1

Anyway, it looks like a bug or maybe a configuration issue ?

thank you for your time

[Mark Reynolds]

On 11/29/19 10:27 AM, Francesc Guasch wrote:
> Hello.
>
> After upgrade to 389 release 1.4 I experienced an odd behaviour.
>
> If I add a new user, then I bind with that user. The userPassword
> attribute gets changed to {PBKDF2_SHA256}.
>
> These are the steps I follow to reproduce it:
>
> 1- add a new entry with MD5 password, it is like this: {MD5}N7...
> 2- connect to LDAP and bind with the user just created
> 3- connect with admin and retrieve the password, it is {PBKDF2_SHA256}

This is the expected behavior.  We now automatically upgrade password 
storage schemes to PBKDF2 in 1.4.2 - which is the strongest hashing 
algorithm we offer.  MD5 is not considered secure anymore. You can 
disable this "hash upgrade" feature by setting: 
nsslapd-enable-upgrade-hash to "off" under cn=config
> I may have been doing something wrong but my code worked on previous
> releases of 389-ds.
>
> I extracted code from my project to build a full test on it. I uploaded
> it to gist:
>
> https://gist.github.com/frankiejol/9e099ba828c8cbdff361783c177643da
>
> This is 1.4.1.6-4. So I have seen there is 1.4.2 release but
> I haven't been able to build it. It gets stuck on make lib389
>
> ModuleNotFoundError: No module named 'packaging'
> make: *** [Makefile:14474: lib389] Error 1

Install "python3-packaging" which is a requirement in our specfile, but 
in master branch we should have changed things to now use python3-distro 
(instead of python3-packaging).  So I'm not sure how your are building 
the server, but I would suggest following this doc:

http://www.port389.org/docs/389ds/development/building.html

HTH,

Mark
> Anyway, it looks like a bug or maybe a configuration issue ?
>
> thank you for your time
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

[William Brown]

> On 30 Nov 2019, at 03:50, Mark Reynolds  wrote:
>
> On 11/29/19 10:27 AM, Francesc Guasch wrote:
> > Hello.
> >
> > After upgrade to 389 release 1.4 I experienced an odd behaviour.
> >
> > If I add a new user, then I bind with that user. The userPassword
> > attribute gets changed to {PBKDF2_SHA256}.
> >
> > These are the steps I follow to reproduce it:
> >
> > 1- add a new entry with MD5 password, it is like this: {MD5}N7...
> > 2- connect to LDAP and bind with the user just created
> > 3- connect with admin and retrieve the password, it is {PBKDF2_SHA256}
>
> This is the expected behavior.  We now automatically upgrade password storage schemes to PBKDF2 in 1.4.2 - which is the strongest hashing algorithm we offer.  MD5 is not considered secure anymore. You can disable this "hash upgrade" feature by setting: nsslapd-enable-upgrade-hash to "off" under cn=config

To echo what Mark has said here, MD5 today should be considered as equivalent to "cleartext" storage. Generally any storage scheme less than SSHA512 should not be used for a variety of security and compliance reasons.

If you are using MD5 for one of the SASL MD5 mechanisms, these are also considered insecure, and you should opt for LDAPS (TLS) with simple bind or SASL-PLAIN instead.
> > I may have been doing something wrong but my code worked on previous
> > releases of 389-ds.
> >
> > I extracted code from my project to build a full test on it. I uploaded
> > it to gist:
> >
> > https://gist.github.com/frankiejol/9e099ba828c8cbdff361783c177643da
> >
> > This is 1.4.1.6-4. So I have seen there is 1.4.2 release but
> > I haven't been able to build it. It gets stuck on make lib389
> >
> > ModuleNotFoundError: No module named 'packaging'
> > make: *** [Makefile:14474: lib389] Error 1
>
> Install "python3-packaging" which is a requirement in our specfile, but in master branch we should have changed things to now use python3-distro (instead of python3-packaging).  So I'm not sure how your are building the server, but I would suggest following this doc:
>
> http://www.port389.org/docs/389ds/development/building.html
>
> HTH,
>
> Mark
> > Anyway, it looks like a bug or maybe a configuration issue ?
> >
> > thank you for your time
> > _______________________________________________
> > 389-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]....
>
> --
>
> 389 Directory Server Development Team
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Francesc Guasch]

El 2/12/19 a les 1:15, William Brown ha escrit:
> > On 30 Nov 2019, at 03:50, Mark Reynolds  wrote:
> > This is the expected behavior.  We now automatically upgrade password storage schemes to PBKDF2 in 1.4.2 - which is the strongest hashing algorithm we offer.  MD5 is not considered secure anymore. You can disable this "hash upgrade" feature by setting: nsslapd-enable-upgrade-hash to "off" under cn=config
>
> To echo what Mark has said here, MD5 today should be considered as equivalent to "cleartext" storage. Generally any storage scheme less than SSHA512 should not be used for a variety of security and compliance reasons.
>
> If you are using MD5 for one of the SASL MD5 mechanisms, these are also considered insecure, and you should opt for LDAPS (TLS) with simple bind or SASL-PLAIN instead.

Mark and William, thank you very much for your kind answers.

I was adding the users using this perl code:

my $apr=Authen::Passphrase::SaltedDigest->new(
      passphrase => $password
    , algorithm => "MD5");

my $userPassword = $apr->as_rfc2307()

Then matching with that:

Authen::Passphrase->from_rfc2307($password_ldap)->match($password);

I see know I have to use another algorithm like SSHA512 instead MD5 and
use PBKDF2 as storage scheme instead rfc2307. But that is not 389
related.

Anyway congratulations for this directory server project and thank
you for your fast and nice support.

[William Brown]

> On 2 Dec 2019, at 18:46, Francesc Guasch  wrote:
>
> El 2/12/19 a les 1:15, William Brown ha escrit:
> > > On 30 Nov 2019, at 03:50, Mark Reynolds  wrote:
> > > This is the expected behavior.  We now automatically upgrade password storage schemes to PBKDF2 in 1.4.2 - which is the strongest hashing algorithm we offer.  MD5 is not considered secure anymore. You can disable this "hash upgrade" feature by setting: nsslapd-enable-upgrade-hash to "off" under cn=config
> >
> > To echo what Mark has said here, MD5 today should be considered as equivalent to "cleartext" storage. Generally any storage scheme less than SSHA512 should not be used for a variety of security and compliance reasons.
> >
> > If you are using MD5 for one of the SASL MD5 mechanisms, these are also considered insecure, and you should opt for LDAPS (TLS) with simple bind or SASL-PLAIN instead.
>
> Mark and William, thank you very much for your kind answers.
>
> I was adding the users using this perl code:
>
> my $apr=Authen::Passphrase::SaltedDigest->new(
>      passphrase => $password
>    , algorithm => "MD5");
>
> my $userPassword = $apr->as_rfc2307()
>
> Then matching with that:
>
> Authen::Passphrase->from_rfc2307($password_ldap)->match($password);

Hmmm you may want to consider using and ldap bind rather than a client side match of the hash content. It's a much more secure and long term supportable way of managing this, and resolves a number of security risks around userPassword attribute disclosure.

https://metacpan.org/pod/Net::LDAP::Examples#BINDING
> I see know I have to use another algorithm like SSHA512 instead MD5 and
> use PBKDF2 as storage scheme instead rfc2307. But that is not 389
> related.

See above, I'd consider you should think about ldap simple binds instead of using the ->match here, then you don't need to work about hashing at all,
> Anyway congratulations for this directory server project and thank
> you for your fast and nice support.

Anytime, and we are always happy to help!
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Francesc Guasch]

El 2/12/19 a les 22:42, William Brown ha escrit:
> > On 2 Dec 2019, at 18:46, Francesc Guasch  wrote:
> >
> > Then matching with that:
> >
> > Authen::Passphrase->from_rfc2307($password_ldap)->match($password);
>
> Hmmm you may want to consider using and ldap bind rather than a client side match of the hash content. It's a much more secure and long term supportable way of managing this, and resolves a number of security risks around userPassword attribute disclosure.
>
> https://metacpan.org/pod/Net::LDAP::Examples#BINDING

Absolutely. Thank you for pointing me to the doc.

We do use binding by default, but we have some use cases
where there is a legacy setup that only works with match.

I have managed to use pbkdf2 and store the passwords properly
with SHA-256. But I still have something missing.

Usually the users entries are already there in the LDAP directory
but we provide a small function to add users. My problem is
we have to create a random salt and I don't know how to store it.

Right now there is a static salt string using PBKDF2::Tiny

my $pass="{PBKDF2_SHA256}"
             .derive_hex( 'SHA-256',$password, 'salt' );
                                                ^^^^

Then I use this to add an entry in the attribute userPassword.
But I don't know how to properly create this string with a
random salt.

What is the string format to store with PBKDF2 ?

[William Brown]

> On 4 Dec 2019, at 18:27, Francesc Guasch  wrote:
>
> El 2/12/19 a les 22:42, William Brown ha escrit:
> > > On 2 Dec 2019, at 18:46, Francesc Guasch  wrote:
> > >
> > > Then matching with that:
> > >
> > > Authen::Passphrase->from_rfc2307($password_ldap)->match($password);
> >
> > Hmmm you may want to consider using and ldap bind rather than a client side match of the hash content. It's a much more secure and long term supportable way of managing this, and resolves a number of security risks around userPassword attribute disclosure.
> >
> > https://metacpan.org/pod/Net::LDAP::Examples#BINDING
>
> Absolutely. Thank you for pointing me to the doc.
>
> We do use binding by default, but we have some use cases
> where there is a legacy setup that only works with match.
>
> I have managed to use pbkdf2 and store the passwords properly
> with SHA-256. But I still have something missing.
>
> Usually the users entries are already there in the LDAP directory
> but we provide a small function to add users. My problem is
> we have to create a random salt and I don't know how to store it.
>
> Right now there is a static salt string using PBKDF2::Tiny
>
> my $pass="{PBKDF2_SHA256}"
>             .derive_hex( 'SHA-256',$password, 'salt' );
>                                                ^^^^
>
> Then I use this to add an entry in the attribute userPassword.
> But I don't know how to properly create this string with a
> random salt.

Because this is salted, you need to provide the same salt to do the match here. Your MD5 was unsalted is why the match works, so you'll need to do much more work now to do the same "match".

In other words you need to do (in psuedo code)

var hashblob = ldap_search('uid=...', 'userPassword')
// hash now contains the PBKDF2_SHA256 value

var (salt, rounds, hash) = hashblob.split ....
// You'll need to look at https://pagure.io/389-ds-base/blob/master/f/ldap/servers/plugins/pwdstorage/..., this "hash" is a base64 encoded blob of data that will require some parsing on your part to setup properly.

var user_hash = pbkdf2.hash(sha256, salt, rounds, plaintext)

assert(user_hash == hash)

It should go without saying, but it's a security risk to have userPassword as a field readable and to do matches like this, so I strongly encourage you to consider updating or modifying the application in question to do binds instead :)

Does that help?
> What is the string format to store with PBKDF2 ?
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Francesc Guasch]

El 5/12/19 a les 1:38, William Brown ha escrit:
>
> Because this is salted, you need to provide the same salt to do the match here. Your MD5 was unsalted is why the match works, so you'll need to do much more work now to do the same "match".
>
> In other words you need to do (in psuedo code)
>
> ...
>
> It should go without saying, but it's a security risk to have userPassword as a field readable and to do matches like this, so I strongly encourage you to consider updating or modifying the application in question to do binds instead :)
>
> Does that help?

Yes it did ! From now on new users are created with the new format
that is also fully 389-ds compatible.

I also added a warning on startup for legacy setups and a recommendation
in the docs.

thank you guys

[William Brown]

> On 9 Dec 2019, at 22:26, Francesc Guasch  wrote:
>
> El 5/12/19 a les 1:38, William Brown ha escrit:
> >
> > Because this is salted, you need to provide the same salt to do the match here. Your MD5 was unsalted is why the match works, so you'll need to do much more work now to do the same "match".
> >
> > In other words you need to do (in psuedo code)
> >
> > ...
> >
> > It should go without saying, but it's a security risk to have userPassword as a field readable and to do matches like this, so I strongly encourage you to consider updating or modifying the application in question to do binds instead :)
> >
> > Does that help?
>
> Yes it did ! From now on new users are created with the new format
> that is also fully 389-ds compatible.
>
> I also added a warning on startup for legacy setups and a recommendation
> in the docs.

Happy to have helped, if you have further questions please let us know!
> thank you guys
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs