Re: [Fedora-directory-users] MD5 for password hashes

[Sam Tran]

On 7/7/05, Sam Tran <stlist(a)gmail.com&gt; wrote:
>  On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>  >  Sam Tran wrote:
>  >  On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>  >
>  >
>  >  Sam Tran wrote:
>  >
>  >
>  >
>  >  Hi all,
>  >
>  > I compiled FDS from the latest sources.
>  >
>  > I migrated a user entry from OpenLDAP to FDS as a test. For that user
>  > entry I tried different password hash schemes for the userPassword
>  > attribute and checked if it was successfully migrated to FDS. Here are
>  > the results:
>  >
>  >
>  >
>  >  Did you run this script first -
>  > http://www.directory.fedora.redhat.com/download/openLDAP2Fedora.pl
>  > - to
>  > migrate the data that used MD5 passwords?
>  >
>  >
>  >
>  >  {CRYPT} --> OK
>  > (MD5} --> FAILED
>  > {SMD5} --> FAILED
>  > {MD5CRYPT} --> OK
>  > {SHA} --> OK
>  > {SSHA} --> OK
>  >
>  > I thought that FDS supported MD5 password hash. Did I miss something?
>  >
>  >
>  >
>  >  Not sure. I would have expected {MD5} to work but not {MD5CRYPT}. See
>  > above.
>  >
>  >
>  >
>  >  Thanks in advance.
>  >
>  > Sam
>  >
>  >
>  >  You should not need to run this script to do the migration. This
>  > script just Base64 decodes the userPassword attribute and puts it in
>  > the form {HASH}xxxxxxxx. FDS apparently understands the Base64 encoded
>  > version of the password.
>  >
>  > For SHA, SSHA, CRYPT and MD5CRYPT I didn't use this script and the
>  > migration was successful. For MD5 I tried without and with the script:
>  > it was unsuccessful in both cases.
>  >
>  >  This is really bizarre, because MD5CRYPT should not work at all - it is not
>  > supported by FDS.  The only thing I can think is that it is interpreting the
>  > value as clear text.
>  >
>  >  How did you verify that the migration was successful?
>  >
>  >  Sam
>  >
>  
>  I simply did a ldapsearch with a binddn:
>  ./ldapsearch -h localhost -b "dc=example,dc=com" -D
>  "uid=joesmith,ou=people,dc=example,dc=com" -w - "objectclass=*"
I create a new user in FDS with a password I generated using this python module:
http://www.sabren.net/code/python/crypt/index.php3

The hash is MD5CRYPT. And it worked.

Try for yourself.

Don't forget to prepend {CRYPT} to the generated password.

Sam

[Fedora-directory-users] MD5 for password hashes

[Rich Megginson]

Sam Tran wrote:

> On 7/7/05, Sam Tran <stlist(a)gmail.com&gt; wrote:
>   
>
> >On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
> >    
> >
> >> Sam Tran wrote:
> >> On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
> >>
> >>
> >> Sam Tran wrote:
> >>
> >>
> >>
> >> Hi all,
> >>
> >>I compiled FDS from the latest sources.
> >>
> >>I migrated a user entry from OpenLDAP to FDS as a test. For that user
> >>entry I tried different password hash schemes for the userPassword
> >>attribute and checked if it was successfully migrated to FDS. Here are
> >>the results:
> >>
> >>
> >>
> >> Did you run this script first -
> >>http://www.directory.fedora.redhat.com/download/openLDAP2Fedora.pl
> >>- to
> >>migrate the data that used MD5 passwords?
> >>
> >>
> >>
> >> {CRYPT} --> OK
> >>(MD5} --> FAILED
> >>{SMD5} --> FAILED
> >>{MD5CRYPT} --> OK
> >>{SHA} --> OK
> >>{SSHA} --> OK
> >>
> >>I thought that FDS supported MD5 password hash. Did I miss something?
> >>
> >>
> >>
> >> Not sure. I would have expected {MD5} to work but not {MD5CRYPT}. See
> >>above.
> >>
> >>
> >>
> >> Thanks in advance.
> >>
> >>Sam
> >>
> >>
> >> You should not need to run this script to do the migration. This
> >>script just Base64 decodes the userPassword attribute and puts it in
> >>the form {HASH}xxxxxxxx. FDS apparently understands the Base64 encoded
> >>version of the password.
> >>
> >>For SHA, SSHA, CRYPT and MD5CRYPT I didn't use this script and the
> >>migration was successful. For MD5 I tried without and with the script:
> >>it was unsuccessful in both cases.
> >>
> >> This is really bizarre, because MD5CRYPT should not work at all - it is not
> >>supported by FDS.  The only thing I can think is that it is interpreting the
> >>value as clear text.
> >>
> >> How did you verify that the migration was successful?
> >>
> >> Sam
> >>
> >>      
> >>
> >I simply did a ldapsearch with a binddn:
> >./ldapsearch -h localhost -b "dc=example,dc=com" -D
> >"uid=joesmith,ou=people,dc=example,dc=com" -w - "objectclass=*"
> >    
> >
>
> I create a new user in FDS with a password I generated using this python module:
> http://www.sabren.net/code/python/crypt/index.php3
>
> The hash is MD5CRYPT. And it worked.
>
> Try for yourself.
>
> Don't forget to prepend {CRYPT} to the generated password.
>   
>  
Ah hah.  That's why it works.  But in FDS, {CRYPT} is not the same as 
MD5 crypt - FDS crypt uses the old unix crypt that used to be the 
standard for Solaris /etc/passwd and /etc/shadow (and other OSes).

dirving, any clues as to why {MD5} doesn't work?

> Sam
>   
>

[Fedora-directory-users] MD5 for password hashes

[Sam Tran]

On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>   Sam Tran wrote: 
>   On 7/7/05, Sam Tran <stlist(a)gmail.com&gt; wrote:
>   
>   
>   On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>   
>   
>   Sam Tran wrote:
>   On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
>  
>  
>   Sam Tran wrote:
>  
>  
>  
>   Hi all,
>  
>  I compiled FDS from the latest sources.
>  
>  I migrated a user entry from OpenLDAP to FDS as a test. For that user
>  entry I tried different password hash schemes for the userPassword
>  attribute and checked if it was successfully migrated to FDS. Here are
>  the results:
>  
>  
>  
>   Did you run this script first -
>  http://www.directory.fedora.redhat.com/download/openLDAP2Fedora.pl
>  - to
>  migrate the data that used MD5 passwords?
>  
>  
>  
>   {CRYPT} --> OK
>  (MD5} --> FAILED
>  {SMD5} --> FAILED
>  {MD5CRYPT} --> OK
>  {SHA} --> OK
>  {SSHA} --> OK
>  
>  I thought that FDS supported MD5 password hash. Did I miss something?
>  
>  
>  
>   Not sure. I would have expected {MD5} to work but not {MD5CRYPT}. See
>  above.
>  
>  
>  
>   Thanks in advance.
>  
>  Sam
>  
>  
>   You should not need to run this script to do the migration. This
>  script just Base64 decodes the userPassword attribute and puts it in
>  the form {HASH}xxxxxxxx. FDS apparently understands the Base64 encoded
>  version of the password.
>  
>  For SHA, SSHA, CRYPT and MD5CRYPT I didn't use this script and the
>  migration was successful. For MD5 I tried without and with the script:
>  it was unsuccessful in both cases.
>  
>   This is really bizarre, because MD5CRYPT should not work at all - it is not
>  supported by FDS. The only thing I can think is that it is interpreting the
>  value as clear text.
>  
>   How did you verify that the migration was successful?
>  
>   Sam
>  
>   
>   I simply did a ldapsearch with a binddn:
>  ./ldapsearch -h localhost -b "dc=example,dc=com" -D
>  "uid=joesmith,ou=people,dc=example,dc=com" -w -
>  "objectclass=*"
>   
>   I create a new user in FDS with a password I generated using this python
>  module:
>  http://www.sabren.net/code/python/crypt/index.php3
>  
>  The hash is MD5CRYPT. And it worked.
>  
>  Try for yourself.
>  
>  Don't forget to prepend {CRYPT} to the generated password.
>   
>   Ah hah.  That's why it works.  But in FDS, {CRYPT} is not the same as MD5
>  crypt - FDS crypt uses the old unix crypt that used to be the standard for
>  Solaris /etc/passwd and /etc/shadow (and other OSes).
>   
>   dirving, any clues as to why {MD5} doesn't work?
>    
Rich,

I believe that {CRYPT} in FDS or OpenLDAP use the system crypt(3) function.

Please read this pages:
http://www.openldap.org/faq/data/cache/344.html
http://www.openldap.org/faq/data/cache/1041.html

The second page says:
"Newer Unix systems also support other password hash algorithms
including MD5 and DES-based hashing with longer than 8 significant
password characters."

When I do a "man crypt" on my Debian box I have the following:
[snip]
GNU EXTENSION
       The glibc2 version of this function has the following
additional features.  If salt is a character string starting with
       the  three  characters  "$1$"  followed  by at most eight
characters, and optionally terminated by "$", then instead of
       using the DES machine, the glibc crypt function uses an
MD5-based  algorithm,  and  outputs  up  to  34  bytes,  namely
       "$1$<string>$",  where  "<string>"  stands for the
up to 8
characters following "$1$" in the salt, followed by 22 bytes
       chosen from the set [a-zA-Z0-9./].  The entire key is
significant here (instead of only the first 8 bytes).
[snip]

The bottom line is that if your system crypt() function supports
MD5-based algorithm, your FDS should support MD5CRYPT. In the
userPassword attribute, you would see {CRYPT}$1<string> for a
"MD5CRYPT" hashed password. I am sorry if I confused you with the
{MD5CRYPT} naming; it is actually a particular type of {CRYPT} hashing
scheme.

Still don't know what {MD5} does not work ...

Thanks.
Sam

[Fedora-directory-users] MD5 for password hashes

[Nathan Benson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam/Rich,

the only way that {MD5} has worked for me in the past (using OpenLDAP)
was if the actual MD5 hash was binary data.  the following are all
hashes of the password "test", and in OL they all work equally:

{CRYPT}ch.V5DKiTQWmc
{CRYPT}$1$cpSVhP8p$v3TgzHRC/fOxBlpUF4ABL1
{MD5}CY9rzUYh03PK3k6DJie09g==

if you decode the base64 encoded {MD5} hash, you will see that it's binary:

perl -MMIME::Base64 -e \
'print decode_base64("CY9rzUYh03PK3k6DJie09g==") . "\n";'

~        ?kÍF!ÓsÊÞN?&'´ö


the only way i was able to use the MD5 hash from the /etc/shadow was to
use {CRYPT} before it and not {MD5}.  i've only done minimal testing
with this in FDS, but i believe you will find the same thing probably
holds true.

ihth,
nb

Sam Tran thus spake on 07/07/2005 02:41 PM:
| On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
|
|> Sam Tran wrote:
|> On 7/7/05, Sam Tran <stlist(a)gmail.com&gt; wrote:
|>
|>
|> On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
|>
|>
|> Sam Tran wrote:
|> On 7/7/05, Rich Megginson <rmeggins(a)redhat.com&gt; wrote:
|>
|>
|> Sam Tran wrote:
|>
|>
|>
|> Hi all,
|>
|>I compiled FDS from the latest sources.
|>
|>I migrated a user entry from OpenLDAP to FDS as a test. For that user
|>entry I tried different password hash schemes for the userPassword
|>attribute and checked if it was successfully migrated to FDS. Here are
|>the results:
|>
|>
|>
|> Did you run this script first -
|>http://www.directory.fedora.redhat.com/download/openLDAP2Fedora.pl
|>- to
|>migrate the data that used MD5 passwords?
|>
|>
|>
|> {CRYPT} --> OK
|>(MD5} --> FAILED
|>{SMD5} --> FAILED
|>{MD5CRYPT} --> OK
|>{SHA} --> OK
|>{SSHA} --> OK
|>
|>I thought that FDS supported MD5 password hash. Did I miss something?
|>
|>
|>
|> Not sure. I would have expected {MD5} to work but not {MD5CRYPT}. See
|>above.
|>
|>
|>
|> Thanks in advance.
|>
|>Sam
|>
|>
|> You should not need to run this script to do the migration. This
|>script just Base64 decodes the userPassword attribute and puts it in
|>the form {HASH}xxxxxxxx. FDS apparently understands the Base64 encoded
|>version of the password.
|>
|>For SHA, SSHA, CRYPT and MD5CRYPT I didn't use this script and the
|>migration was successful. For MD5 I tried without and with the script:
|>it was unsuccessful in both cases.
|>
|> This is really bizarre, because MD5CRYPT should not work at all - it
is not
|>supported by FDS. The only thing I can think is that it is
interpreting the
|>value as clear text.
|>
|> How did you verify that the migration was successful?
|>
|> Sam
|>
|>
|> I simply did a ldapsearch with a binddn:
|>./ldapsearch -h localhost -b "dc=example,dc=com" -D
|>"uid=joesmith,ou=people,dc=example,dc=com" -w -
|>"objectclass=*"
|>
|> I create a new user in FDS with a password I generated using this python
|>module:
|>http://www.sabren.net/code/python/crypt/index.php3
|>
|>The hash is MD5CRYPT. And it worked.
|>
|>Try for yourself.
|>
|>Don't forget to prepend {CRYPT} to the generated password.
|>
|> Ah hah.  That's why it works.  But in FDS, {CRYPT} is not the same as MD5
|>crypt - FDS crypt uses the old unix crypt that used to be the standard for
|>Solaris /etc/passwd and /etc/shadow (and other OSes).
|>
|> dirving, any clues as to why {MD5} doesn't work?
|>
|
|
| Rich,
|
| I believe that {CRYPT} in FDS or OpenLDAP use the system crypt(3)
function.
|
| Please read this pages:
| http://www.openldap.org/faq/data/cache/344.html
| http://www.openldap.org/faq/data/cache/1041.html
|
| The second page says:
| "Newer Unix systems also support other password hash algorithms
| including MD5 and DES-based hashing with longer than 8 significant
| password characters."
|
| When I do a "man crypt" on my Debian box I have the following:
| [snip]
| GNU EXTENSION
|        The glibc2 version of this function has the following
| additional features.  If salt is a character string starting with
|        the  three  characters  "$1$"  followed  by at most eight
| characters, and optionally terminated by "$", then instead of
|        using the DES machine, the glibc crypt function uses an
| MD5-based  algorithm,  and  outputs  up  to  34  bytes,  namely
|        "$1$<string>$",  where  "<string>"  stands for
the up to 8
| characters following "$1$" in the salt, followed by 22 bytes
|        chosen from the set [a-zA-Z0-9./].  The entire key is
| significant here (instead of only the first 8 bytes).
| [snip]
|
| The bottom line is that if your system crypt() function supports
| MD5-based algorithm, your FDS should support MD5CRYPT. In the
| userPassword attribute, you would see {CRYPT}$1<string> for a
| "MD5CRYPT" hashed password. I am sorry if I confused you with the
| {MD5CRYPT} naming; it is actually a particular type of {CRYPT} hashing
| scheme.
|
| Still don't know what {MD5} does not work ...
|
| Thanks.
| Sam
|
| --
| Fedora-directory-users mailing list
| Fedora-directory-users(a)redhat.com
| https://www.redhat.com/mailman/listinfo/fedora-directory-users
|

- --
Nathan Benson
http://sourcefire.com/

1C1A F2C1 82AD F75F 9B6B  E501 0D73 DC9B E96B DD96
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQFCzpbmDXPcm+lr3ZYRAlNyAKClfLwJc2ScuGr+Gu7c7a++dM8ftACffWkp
> lv2M8IvtPmRLYYbESYJXgak=
> =p6TD
> -----END PGP SIGNATURE-----