Hello,
We are authenticating from some Java written software against an OpenLDAP system by reading the users 'userPassword' LDAP attribute, calculating the clear text password against the SSHA hash string.
It turned out that some (a few number) of these hash are stored in the form:
userPassword:: e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==
which decodes to:
$ echo 'e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==' | openssl base64 -d {ssha}GkR9OuHhNjAhg0VySmcBGEA9ocLUNFefgcEZ1w==
i.e. with SSHA in small letters. It's only 1 of thousand users having the tag as '{ssha}'.
Why is this?
Thanks
matthias
Matthias Apitz wrote:
Hello,
We are authenticating from some Java written software against an OpenLDAP system by reading the users 'userPassword' LDAP attribute, calculating the clear text password against the SSHA hash string.
That's the wrong way to authenticate against credentials stored in an LDAP directory. You should just do an LDAP Bind.
It turned out that some (a few number) of these hash are stored in the form:
userPassword:: e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==
which decodes to:
$ echo 'e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==' | openssl base64 -d {ssha}GkR9OuHhNjAhg0VySmcBGEA9ocLUNFefgcEZ1w==
i.e. with SSHA in small letters. It's only 1 of thousand users having the tag as '{ssha}'.
Why is this?
Probably you have some clients updating their entries with hashed passwords instead of letting slapd do all the hashing. Again, that is not a good practice.
El día Tuesday, September 29, 2015 a las 08:22:36AM +0100, Howard Chu escribió:
We are authenticating from some Java written software against an OpenLDAP system by reading the users 'userPassword' LDAP attribute, calculating the clear text password against the SSHA hash string.
That's the wrong way to authenticate against credentials stored in an LDAP directory. You should just do an LDAP Bind.
I do not know (the Java classes have beed written by others) why we do not just doe bind, What what is wrong with our method.
It turned out that some (a few number) of these hash are stored in the form:
userPassword:: e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==
which decodes to:
$ echo 'e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==' | openssl base64 -d {ssha}GkR9OuHhNjAhg0VySmcBGEA9ocLUNFefgcEZ1w==
i.e. with SSHA in small letters. It's only 1 of thousand users having the tag as '{ssha}'.
Why is this?
Probably you have some clients updating their entries with hashed passwords instead of letting slapd do all the hashing. Again, that is not a good practice.
This part is not below our control. The LDAP is managed by some customer and I *think* the use some Perl script to create the user credentials in LDAP, calculating tha SSHA hash in advance.
Thanks for your feedback in any case.
matthias
-- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Tue, Sep 29, 2015 at 09:31:20AM +0200, Matthias Apitz wrote:
I do not know (the Java classes have beed written by others) why we do not just doe bind, What what is wrong with our method.
It requires read access to the password hash, which is a security risk. Most LDAP deployments prevent *anyone* from reading password hashes (except for the replication user etc).
Hashing passwords and verifying them should be left to the LDAP server.
Note also that SSHA is very weak in the face of brute-force attacks. You should be trying to use one of the hash schemes that were designed specifically to protect passwords. BCRYPT is probably the best, but any of the Linux $1$, $6$, $2a$ schemes will give immensely more protection than plain SSHA.
This part is not below our control. The LDAP is managed by some customer and I *think* the use some Perl script to create the user credentials in LDAP, calculating tha SSHA hash in advance.
Advise them to create the entry without a password hash, then to set the password using the password-change extended operation.
See Net::LDAP::Extension::SetPassword for details.
Andrew
Matthias Apitz wrote:
We are authenticating from some Java written software against an OpenLDAP system by reading the users 'userPassword' LDAP attribute, calculating the clear text password against the SSHA hash string.
Are you sure you want to do that? You should rather send a simple bind request to the server to let slapd check the password.
+ Then you can disallow read access to 'userPassword' to protect the password hashes against application hacks. + You can use stronger password hashing schemes supported by slapd nowadays. + slapd can enforce a password policy.
which decodes to:
$ echo 'e3NzaGF9R2tSOU91SGhOakFoZzBWeVNtY0JHRUE5b2NMVU5GZWZnY0VaMXc9PQ==' | openssl base64 -d {ssha}GkR9OuHhNjAhg0VySmcBGEA9ocLUNFefgcEZ1w==
i.e. with SSHA in small letters. It's only 1 of thousand users having the tag as '{ssha}'.
The scheme string is case-insensitive. Your application has to deal with that if you insist on doing it this wrong way.
https://tools.ietf.org/html/draft-stroeder-hashed-userpassword-values-01#sec...
Ciao, Michael.
openldap-technical@openldap.org
-
Andrew Findlay -
Howard Chu -
Matthias Apitz -
Michael Ströder