Re: userPassword encryption SHA

[Rick van Rein <rick@vanrein.org>]

Hi Ivan Rodriguez Aguilar,

> i have use SHA for the password encryption 
> my gui client gq show  the password in format ldif 
> {SHA}Gxkq3dasdf= (for example)

Where the part after "{SHA}" is the base64-encoded 20-byte hash code.
(So it's longer in reality, about 20*8/6=28 chars, as you also show below.)

> but ldapsearch not show me the userpassword in format ldif 
> somebody know how to ?

Actually, what you get is correct LDIF, but the representation is not
ASCII as used for most readable fields.  Not sure why that choice is made.

> ldapsearch -x -D "cn=Manager,o=mycom" -b "o=mycom" -w secret
> "mail=ivan@mycom" -LLL 
> 
> show me:
> 
> userPassword:: e1NIQX1HNHh1N2sxNlBuMnRVSDk4cFRNOVM3RjV0d2s9
 
              ^^ This is what says that it's base64-represented.
Actually, the {SHA}xxx also contains "xxx" in base64-representation.
The only thing that happens here is that all of "{SHA}xxx" is represented 
in base64, so "xxx" is actually encoded twice.
So the whole thing has now grown to around (28+5)*8/6=44 chars.  But since
that's only a temporary representation, it doesn't matter that much.

On BSD/Linux, you can revert using a base64-decode, such as mimencode with
a -u option, as follows:
  prompt$ echo e1NIQX1HNHh1N2sxNlBuMnRVSDk4cFRNOVM3RjV0d2s9 | mimencode -u
  {SHA}G4xu7k16Pn2tUH98pTM9S7F5twk=
And there's what you needed.  The line
  userPassword:: e1NIQX1HNHh1N2sxNlBuMnRVSDk4cFRNOVM3RjV0d2s9
is equivalent to
  userPassword: {SHA}G4xu7k16Pn2tUH98pTM9S7F5twk=
where you should notice the intentionally different number of colons.
If you wanted to obtain the actual 20-byte SHA1-hash, you would repeat the
procedure for the "inner" base64-encoding,
  prompt$ echo G4xu7k16Pn2tUH98pTM9S7F5twk= | mimencode -u >pwdhash

This is where the decoding ends, of course.  A SHA-1 hash cannot be decoded
to obtain the password.  Pfew ;-)

> userPassword: {SHA}G4xu7k16Pn2tUH98pTM9S7F5twk=

Yes, that's what I found in the above.  


Cheers,

Rick van Rein.