Hi.
I have user information in RDB which include user-id and password set.
I’ve been trying to use this RDB as backend database for openldap server.
Now,I can find user information in RDB through openldap.
However, I recognized I can’t use this user information for ldap login certification process.
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
Now I’d like my openldap to change CREATEXT input password into DES hassed text so that they'll match for certification.
I've asked this topic on stackoverflow web site how to do that by server settings.But I couldn’t find proper directives to set.
How to make ldap evaluate clear text password vs DES stored password
Since then,I’ve been searching LDAP source files which is matching input password from ldapsearch command line against userPassword stored in backend RDB for slapd.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text.
If I can make opeldap to act this way,I can use user's infomation in the RDB to ldap login inforomation wiht seamless.
Hi!
I think that traditional UNIX crypt passwords are obsolete for at least 10 years. I also think that there are online services that could decode your DES-encoded challenges in a few seconds if not even faster...
What I mean to says is: Don't spend time in getting DES passwords, upgrade your security instead.
Modern systems encode passwords like this (note the difference in length!): :$6$CM21wofswJzjH.NfEtuX3m6Hjtx4H0mLq4MID3JqK254DCIw6Sjeh1kmI27DEwcAb8ilxb8KH08PmQIcTD8XloWFAXKmC/uuR1
See man crypt(3) for glibc: I knows about: Traditional DES-based Extended BSDI-style DES-based FreeBSD-style MD5-based SHA256 based SHA512 based OpenBSD-style Blowfish-based (bcrypt)
So I guess you get the idea...
Regards, Ulrich
yokoyamy@jacic.or.jp schrieb am 20.09.2018 um 01:43 in Nachricht
201809192343.w8JNh4VT026857@mbox.securemx.jp:
Hi.
I have user information in RDB which include user‑id and password set.
I’ve been trying to use this RDB as backend database for openldap server.
Now,I can find user information in RDB through openldap.
However, I recognized I can’t use this user information for ldap login certification process.
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line
is CREARTEXT.
Now I’d like my openldap to change CREATEXT input password into DES hassed text so that they'll match for certification.
I've asked this topic on stackoverflow web site how to do that by server settings.But I couldn’t find proper directives to set.
How to make ldap evaluate clear text password vs DES stored password
Since then,I’ve been searching LDAP source files which is matching input password from ldapsearch command line against userPassword stored in backend
RDB for slapd.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be
able to find out what will be SALT to make input password into DES hashed text.
If I can make opeldap to act this way,I can use user's infomation in the RDB
to ldap login inforomation wiht seamless.
Thanks for your advice. but i have no chicese to use DES in this case. i must do that even it'll be temporary.
in message "Antw: How to make ldap evaluate clear text password vs DES stored password", "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
I think that traditional UNIX crypt passwords are obsolete for at least 10 years. I also think that there are online services that could decode your DES-encoded challenges in a few seconds if not even faster...
What I mean to says is: Don't spend time in getting DES passwords, upgrade your security instead.
Modern systems encode passwords like this (note the difference in length!): :$6$CM21wofswJzjH.NfEtuX3m6Hjtx4H0mLq4MID3JqK254DCIw6Sjeh1kmI27DEwcAb8ilxb8KH08PmQIcTD8XloWFAXKmC/uuR1
See man crypt(3) for glibc: I knows about: Traditional DES-based Extended BSDI-style DES-based FreeBSD-style MD5-based SHA256 based SHA512 based OpenBSD-style Blowfish-based (bcrypt)
So I guess you get the idea...
Regards, Ulrich
yokoyamy@jacic.or.jp schrieb am 20.09.2018 um 01:43 in Nachricht
201809192343.w8JNh4VT026857@mbox.securemx.jp:
Hi.
I have user information in RDB which include user?id and password set.
I’ve been trying to use this RDB as backend database for openldap server.
Now,I can find user information in RDB through openldap.
However, I recognized I can’t use this user information for ldap login certification process.
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line
is CREARTEXT.
Now I’d like my openldap to change CREATEXT input password into DES hassed text so that they'll match for certification.
I've asked this topic on stackoverflow web site how to do that by server settings.But I couldn’t find proper directives to set.
How to make ldap evaluate clear text password vs DES stored password
Since then,I’ve been searching LDAP source files which is matching input password from ldapsearch command line against userPassword stored in backend
RDB for slapd.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be
able to find out what will be SALT to make input password into DES hashed text.
If I can make opeldap to act this way,I can use user's infomation in the RDB
to ldap login inforomation wiht seamless.
On 09/20/18 08:43 +0900, yokoyamy@jacic.or.jp wrote:
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text.
If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide.
Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
Thanks.
My CentOS can make cleartext into DES .
hete is a part of my previous slapd.conf
olcPasswordHash: {CRYPT} olcSizeLimit: 5000 olcPasswordCryptSaltFormat: "_%s"
unfortunately,it didn't work for my issue.
i think my slapd uses DES when i try to store new userPasword.
However,in this case,i've already have DES hashed userrPassword and been trying to match it with input password from ldapsearch command.
i think unless i fetch userPasdword from RDB through slapd, i will not be able to find SALT in userPassword.
how can i tell slapd that SALT for DES will be the first two letters in stored userPassword?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White dwhite@cafedemocracy.org wrote:
On 09/20/18?08:43?+0900, yokoyamy@jacic.or.jp wrote:
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text.
If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide.
Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White dwhite@cafedemocracy.org wrote:
On 09/20/18?08:43?+0900, yokoyamy@jacic.or.jp wrote:
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide.
Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
On 09/20/18 23:27 +0900, yokoyamy@jacic.or.jp wrote:
My CentOS can make cleartext into DES .
hete is a part of my previous slapd.conf
olcPasswordHash: {CRYPT} olcSizeLimit: 5000 olcPasswordCryptSaltFormat: "_%s"
unfortunately,it didn't work for my issue.
i think my slapd uses DES when i try to store new userPasword.
slapd will not really be concerned about the format of your hash, as long as your underlyding crypt(3) supports it. slapd will pass the cleartext password received from the client to crypt. You will need to consult your cyrpt(3) manpage for what is supported, and for what format it expects to receive ($id$rounds=yyy$salt$encrypts).
i think unless i fetch userPasdword from RDB through slapd, i will not be able to find SALT in userPassword.
If your RDB has a pam authentication module, then that may be a more appropriate route. In that case you would not need to make any of your RDB password hashes directly available to slapd. slapd would pass the cleartext password, from the client, down to the pam module by way of pass-through authentication and saslauthd.
Also, you should be taking appropriate security measures to protect the cleartext password over the wire (ldaps/STARTTLS).
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
Or I did not understood your question.
Best regards,
Olivier
Hi.thanks for your advice.
My cas is a bit complicated.
DES hashed text stored in my RDB is actually cleartext for the RDB itself.
slapd/ldapsearch show it as cleare text with base64 .
When i give original password,certification process returns invalid credential, but when i give DES hashed text which is same value of the RRD,certification succeed as you wrote.
However,I'd like slapd/ldasearch to change input password to same value in the RDB instead of typing by myslf because,I can read the RDB directory but others can't.
I've confirmed my crypt can hash the text into same value of text in theRDB.
Any idea?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
Or I did not understood your question.
Best regards,
Olivier
yokoyamy@jacic.or.jp writes:
Hi.thanks for your advice.
My cas is a bit complicated.
DES hashed text stored in my RDB is actually cleartext for the RDB itself.
slapd/ldapsearch show it as cleare text with base64 .
If your RDB is storing a DES password compatible for LDAP, it must store a character sting of the form "{CRYPT}F6ojc88jnbdc".
The {CRYPT} part is telling LDAP that the string is a DES password. If there is no {CRYPT} part, LDAP assumes that the string is a cleartext password (this is confirmed by what you say below, you can connect if you type the base64/DES text).
So you should:
- take whatever password text that is currently stored in RDB - remove base64 - append {CRYPT} at the begining - store that back in RDB
The RDB will now be storing a DES password that LDAP can use.
I suggest that you test with one account before changing all accounts.
Does any system use the password in RDB or only LDAP? If only LDAP, you can modify all passwords. If other system use the password, you must have one password in LDAP format ({CRYPT} no base64) and one password for the other applications (no {CRYPT} and base64). Or you must find a way for the RDB to present a different password to LDAP and to the other application (for example, depending on the IP address of the client asking for the password).
Best regards,
Olivier
When i give original password,certification process returns invalid credential, but when i give DES hashed text which is same value of the RRD,certification succeed as you wrote.
However,I'd like slapd/ldasearch to change input password to same value in the RDB instead of typing by myslf because,I can read the RDB directory but others can't.
I've confirmed my crypt can hash the text into same value of text in theRDB.
Any idea?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
Or I did not understood your question.
Best regards,
Olivier
It makes sense.Thanks.
I'll try your method next week and will report its result.
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
yokoyamy@jacic.or.jp writes:
Hi.thanks for your advice.
My cas is a bit complicated.
DES hashed text stored in my RDB is actually cleartext for the RDB itself.
slapd/ldapsearch show it as cleare text with base64 .
If your RDB is storing a DES password compatible for LDAP, it must store a character sting of the form "{CRYPT}F6ojc88jnbdc".
The {CRYPT} part is telling LDAP that the string is a DES password. If there is no {CRYPT} part, LDAP assumes that the string is a cleartext password (this is confirmed by what you say below, you can connect if you type the base64/DES text).
So you should:
- take whatever password text that is currently stored in RDB
- remove base64
- append {CRYPT} at the begining
- store that back in RDB
The RDB will now be storing a DES password that LDAP can use.
I suggest that you test with one account before changing all accounts.
Does any system use the password in RDB or only LDAP? If only LDAP, you can modify all passwords. If other system use the password, you must have one password in LDAP format ({CRYPT} no base64) and one password for the other applications (no {CRYPT} and base64). Or you must find a way for the RDB to present a different password to LDAP and to the other application (for example, depending on the IP address of the client asking for the password).
Best regards,
Olivier
When i give original password,certification process returns invalid credential, but when i give DES hashed text which is same value of the RRD,certification succeed as you wrote.
However,I'd like slapd/ldasearch to change input password to same value in the RDB instead of typing by myslf because,I can read the RDB directory but others can't.
I've confirmed my crypt can hash the text into same value of text in theRDB.
Any idea?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
Or I did not understood your question.
Best regards,
Olivier
--
Hi.
you've gat solve my problem.Thank you so much.
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
yokoyamy@jacic.or.jp writes:
Hi.thanks for your advice.
My cas is a bit complicated.
DES hashed text stored in my RDB is actually cleartext for the RDB itself.
slapd/ldapsearch show it as cleare text with base64 .
If your RDB is storing a DES password compatible for LDAP, it must store a character sting of the form "{CRYPT}F6ojc88jnbdc".
The {CRYPT} part is telling LDAP that the string is a DES password. If there is no {CRYPT} part, LDAP assumes that the string is a cleartext password (this is confirmed by what you say below, you can connect if you type the base64/DES text).
So you should:
- take whatever password text that is currently stored in RDB
- remove base64
- append {CRYPT} at the begining
- store that back in RDB
The RDB will now be storing a DES password that LDAP can use.
I suggest that you test with one account before changing all accounts.
Does any system use the password in RDB or only LDAP? If only LDAP, you can modify all passwords. If other system use the password, you must have one password in LDAP format ({CRYPT} no base64) and one password for the other applications (no {CRYPT} and base64). Or you must find a way for the RDB to present a different password to LDAP and to the other application (for example, depending on the IP address of the client asking for the password).
Best regards,
Olivier
When i give original password,certification process returns invalid credential, but when i give DES hashed text which is same value of the RRD,certification succeed as you wrote.
However,I'd like slapd/ldasearch to change input password to same value in the RDB instead of typing by myslf because,I can read the RDB directory but others can't.
I've confirmed my crypt can hash the text into same value of text in theRDB.
Any idea?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Olivier Olivier.Nicole@cs.ait.ac.th wrote:
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
Or I did not understood your question.
Best regards,
Olivier
--
Hi,
I am glad I could help. and thank you for letting me know I could give the right answer.
Good luck,
Olivier
Am Fri, 21 Sep 2018 09:09:40 +0700 schrieb Olivier Olivier.Nicole@cs.ait.ac.th:
Hi,
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
That is how LDAP works if it knows that your passwrd is DES.
But the encoding for DES by LDAP may be slightly different from the encoding for DES by your original app.
For a DES encrypted password, LDAP expects to see: userpassword: {CRYPT}6FgwLHWxQzlgA where 6F is the salt (LDAP knows that the 6F is the salt)
So if your RDB only contains 6FgwLHWxQzlgA, you may have to modify that.
[...] slappasswd(8) provides some information on password hashing and salting.
-Dieter
I can't find 'Pass-Through authentication (section 14.5)' in slapd-config(5) man page.
Could you send me its URL?
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White dwhite@cafedemocracy.org wrote:
On 09/20/18?08:43?+0900, yokoyamy@jacic.or.jp wrote:
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT.
I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed.
So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text.
If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide.
Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
On 09/21/18 12:04 +0900, yokoyamy@jacic.or.jp wrote:
I can't find 'Pass-Through authentication (section 14.5)' in slapd-config(5) man page.
Could you send me its URL?
Thanks.I'll read it carefully.
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White dwhite@cafedemocracy.org wrote:
On 09/21/18?12:04?+0900, yokoyamy@jacic.or.jp wrote:
I can't find 'Pass-Through authentication (section 14.5)' in slapd-config(5) man page.
Could you send me its URL?
openldap-technical@openldap.org
-
Dan White -
Dieter Klünter -
Olivier -
Ulrich Windl -
yokoyamy＠jacic.or.jp