9:27 a.m.
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
11:50 a.m.
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 -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
--
389 Directory Server Development Team
6:15 p.m.
On 30 Nov 2019, at 03:50, Mark Reynolds <mreynolds(a)redhat.com>
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 -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproje...
--
389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
2:46 a.m.
El 2/12/19 a les 1:15, William Brown ha escrit:
> On 30 Nov 2019, at 03:50, Mark Reynolds <mreynolds(a)redhat.com> 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.
3:42 p.m.
On 2 Dec 2019, at 18:46, Francesc Guasch
<frankie(a)telecos.upc.edu> wrote:
El 2/12/19 a les 1:15, William Brown ha escrit:
>
>
>> On 30 Nov 2019, at 03:50, Mark Reynolds <mreynolds(a)redhat.com> 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 -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
2:27 a.m.
El 2/12/19 a les 22:42, William Brown ha escrit:
> On 2 Dec 2019, at 18:46, Francesc Guasch <frankie(a)telecos.upc.edu> 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 ?
6:38 p.m.
On 4 Dec 2019, at 18:27, Francesc Guasch
<frankie(a)telecos.upc.edu> wrote:
El 2/12/19 a les 22:42, William Brown ha escrit:
>
>
>> On 2 Dec 2019, at 18:46, Francesc Guasch <frankie(a)telecos.upc.edu> 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/pwdstora...,
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 -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
6:26 a.m.
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
4:18 p.m.
On 9 Dec 2019, at 22:26, Francesc Guasch
<frankie(a)telecos.upc.edu> 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 -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
1600
days inactive
1610
days old
389-users@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Francesc Guasch -
Mark Reynolds -
William Brown