Hi,
I am storing users passwords in a userPassword attribute. When the passwords are hashed with MD5 I can bind as the user just fine. If I hash the password with sha-256 I get invalid credentials.
Is there something I have to change in my client? Is there something I have to change on the server?
Is binding a user with a password stored with sha-256 (or at least something better then md5) even possible?
Thanks,
--On Thursday, August 28, 2014 5:26 PM -0400 Bram Cymet bcymet@cbnco.com wrote:
Hi,
I am storing users passwords in a userPassword attribute. When the passwords are hashed with MD5 I can bind as the user just fine. If I hash the password with sha-256 I get invalid credentials.
Is there something I have to change in my client? Is there something I have to change on the server?
Is binding a user with a password stored with sha-256 (or at least something better then md5) even possible?
Yes, if you correctly use the passwd contrib module allowing non-RFC hashes.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Bram Cymet bcymet@cbnco.com schrieb am 28.08.2014 um 22:26 in Nachricht
Hi,
I am storing users passwords in a userPassword attribute. When the passwords are hashed with MD5 I can bind as the user just fine. If I hash the password with sha-256 I get invalid credentials.
I wonder: My slappasswd only knows about {SHA} and {SSHA}, {MD5} and {SMD5}, {CRYPT}, and {CLEARTEXT}. Section 14.4 of the manual indicates that hashed passwords are non-standard anyway. So implement the non-standard on your clients.
Is there something I have to change in my client? Is there something I have to change on the server?
Is binding a user with a password stored with sha-256 (or at least something better then md5) even possible?
Thanks,
-- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752
Ulrich Windl wrote:
Bram Cymet bcymet@cbnco.com schrieb am 28.08.2014 um 22:26 in Nachricht
Hi,
I am storing users passwords in a userPassword attribute. When the passwords are hashed with MD5 I can bind as the user just fine. If I hash the password with sha-256 I get invalid credentials.
I wonder: My slappasswd only knows about {SHA} and {SSHA}, {MD5} and {SMD5},
{CRYPT}, and {CLEARTEXT}. Section 14.4 of the manual indicates that hashed passwords are non-standard anyway.
So implement the non-standard on your clients.
No, that's terrible advice. The server should be responsible for all hashing and verification of hashes, otherwise you are guaranteed to get different behavior with different clients. This is the reason why the LDAP Bind operation behaves as it does, and it is the reason why the LDAP PasswordModify operation exists.
Is there something I have to change in my client? Is there something I have to change on the server?
Is binding a user with a password stored with sha-256 (or at least something better then md5) even possible?
Thanks,
--On Friday, August 29, 2014 9:55 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Bram Cymet bcymet@cbnco.com schrieb am 28.08.2014 um 22:26 in Nachricht
Hi,
I am storing users passwords in a userPassword attribute. When the passwords are hashed with MD5 I can bind as the user just fine. If I hash the password with sha-256 I get invalid credentials.
I wonder: My slappasswd only knows about {SHA} and {SSHA}, {MD5} and {SMD5}, {CRYPT}, and {CLEARTEXT}. Section 14.4 of the manual indicates that hashed passwords are non-standard anyway. So implement the non-standard on your clients.
It takes 5 seconds to look in the contrib directory shipped with the source and find:
SHA-2 OpenLDAP support ----------------------
slapd-sha2.c provides support for SSHA-512, SSHA-384, SSHA-256, SHA-512, SHA-384 and SHA-256 hashed passwords in OpenLDAP. For instance, one could have the LDAP attribute:
userPassword: {SHA512}vSsar3708Jvp9Szi2NWZZ02Bqp1qRCFpbcTZPdBhnWgs5WtNZKnvCXdhztmeD2cmW192CF5bDufKRpayrW/isg==
or:
userPassword: {SHA384}WKd1ukESvjAFrkQHznV9iP2nHUBJe7gCbsrFTU4//HIyzo3jq1rLMK45dg/ufFPt
or:
userPassword: {SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
all of which encode the password 'secret'.
(etc). As I already stated, there's a module for this. I use it on my systems to add SSHA512 suport.
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Bram Cymet -
Howard Chu -
Quanah Gibson-Mount -
Ulrich Windl