Re: Decrypting SHA encrypted passwords?

[Jim Dutton <jimd@siu.edu>]

Right. When I upgraded to OpenLDAP V2 and defined my own locally needed
password attributes specifying them with 'SUP userPassword', they all got
SHA encrypted. With OpenLDAP V1, I had defined them as CES. I didn't
realize it, but now do, that ALL 'userPassword' attribute types get
encrypted (silly me).

Thanks to others for suggestions. ACL control is/was already in place for
the specific attributes. Since the application that I have derives the
required external session password FROM LDAP (ie; no password
"seed" available), I guess that I need to go back to a CES type definition
for them. Oh well. Now if there just were FTP, and other servers, that
could handle SHA encrypted passwords (not certificates) .....


On Sun, 25 Feb 2001, Nicholas Oddson wrote:

> Date: Sun, 25 Feb 2001 19:16:45 -0500
> From: Nicholas Oddson <noddson@b2bscene.com>
> To: openldap-software@OpenLDAP.org
> Subject: Re: Decrypting SHA encrypted passwords?
> 
> That's correct.
> 
> If you are looking to use the password attributes that are stored within 
> LDAP in some other context (i.e. retrieve them and use them for 
> authentication to an FTP server), you are not likely to find success.  SHA1 
> and the other algorithms used are strictly one way (i.e. hashing functions).
> 
> There may be a way to configure LDAP to use a reversible algorithm, but I 
> doubt it.
> 
> That means, (1) either have the user supply the password or (2) store the 
> external resource password in another form in a different attribute that is 
> only retrievable in an authenticated context
> 
> - Nick
> 
> At 06:13 PM 25/02/2001, Adam Shand wrote:
> 
> > > How does an application that does not do any password
> > > encrypting/decrypting on its own, such as a script using LDAPSEARCH,
> > > get access to LDAP passwords to use in a clear-text context such as
> > > FTP?
> >
> >i believe the way that this works is that the application passes the
> >password in clear text to the ldap search which then encrypts the clear
> >text password (based of the seed), does a comparision to see if it matches
> >and then returns sucess or failure ot the application which in turn then
> >allows or disallows access.
> >
> >the other possible way for it to work would be for the application to
> >request the encrypted password from the server, encrypt the password it's
> >self and do the comparision internally.  this would require the app to
> >have read access to all of the users passwords though where the other way
> >just requires auth access.
> >
> >adam.
> 
>