Hi,
I did some digging on this issue. I suspect I have found a bug in Fedora Directory Server handling the importing of MD5 passwords, either that or the current download versions don't support MD5.
The results are as follows:
--
Run this command on OpenLDAP to set a user's password:
ldappasswd -x -D 'uid=root,ou=People,dc=babel,dc=com,dc=au' -W -S 'uid=del,ou=People,dc=babel,dc=com,dc=au'
Do a simple ldapsearch as that user, to verify that the password is correct:
ldapsearch -x -D 'uid=del,ou=People,dc=babel,dc=com,dc=au' -W 'uid=del'
If you have set your OpenLDAP permissions to be relatively transparent, the above ldapsearch will show a base64 representation of your password hash. It looks like this:
userPassword:: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
You can un-base64 this hash with the following simple perl script:
#!/usr/bin/perl # # Usage: $0 string # use MIME::Base64; my $data = $ARGV[0]; print("Input string is " . $data . "n"); $decoded = decode_base64($data); print("Decoded string is " . $decoded . "n");
You will see that the password contains the prefix {MD5}, which looks like this:
Decoded string is {MD5}asdfasdfasdfasdfasdf==
Import your OpenLDAP directory into Fedora Directory Server. I used LdapImport for this although I also tried it with ldif2db.
What happens during the process of LdapImport is:
* Passwords of type {CRYPT} are transferred across OK to the FedoraDirectoryServer. * Passwords of type {MD5} appear in the FedoraDirectoryServer as strings beginning with {SSHA}. This can be verified by examining the directory using GQ or a similar LDAP tool, while bound as "cn=Directory Manager". * Attempts to authenticate with the original password now fail. * Attempting to authenticate as the full MD5 string (i.e. use the hash string '{MD5}asdfasdf...==' as extracted from the OpenLDAP server as the password for Fedora Directory Server) in fact works.
I expect that what has happened is that Fedora Directory Server has failed to recognise the {MD5} at the beginning of the string as a valid hash mechanism and re-encoded the entire string as an SSHA hash.
I see that on the FDS wiki there is mention of MD5 hashing support being added on June 15th. I have fedora-ds-7.1-2.RHEL4 installed from the RPM I downloaded from the FDS web site. How do I verify that this version should have the MD5 support, or do I need a more recent version?
I see that on the FDS wiki there is mention of MD5 hashing support being added on June 15th. I have fedora-ds-7.1-2.RHEL4 installed from the RPM I downloaded from the FDS web site. How do I verify that this version should have the MD5 support, or do I need a more recent version?
Here's the answer to my question:
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
OpenLDAP supports MD5 for password hashes. Support has recently been added (6/14/05) for this to Fedora DS (source code only, no binaries yet).
Any chance of some RPMs for the latest edition with the MD5 support please guys?
Del wrote:
I see that on the FDS wiki there is mention of MD5 hashing support being added on June 15th. I have fedora-ds-7.1-2.RHEL4 installed from the RPM I downloaded from the FDS web site. How do I verify that this version should have the MD5 support, or do I need a more recent version?
Here's the answer to my question:
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration
OpenLDAP supports MD5 for password hashes. Support has recently been added (6/14/05) for this to Fedora DS (source code only, no binaries yet).
Any chance of some RPMs for the latest edition with the MD5 support please guys?
We're working on it.
Rich Megginson wrote:
Any chance of some RPMs for the latest edition with the MD5 support
please guys?
We're working on it.
Hi,
I hate to be a pest with this but I now have 3 clients with fairly large FDS / RHDS implementations planned, which are now on hold waiting for this release.
Is there a planned release date for this? I've foolishly suggested to one of them that it could take no longer than the end of next month, so I need to know if I'm likely to have to do some backpedalling on that date.
Thanx,
We hope to have another binary release by the end of the week. We've just got a couple of bug fixes to go.
Del wrote:
Rich Megginson wrote:
Any chance of some RPMs for the latest edition with the MD5 support
please guys?
We're working on it.
Hi,
I hate to be a pest with this but I now have 3 clients with fairly large FDS / RHDS implementations planned, which are now on hold waiting for this release.
Is there a planned release date for this? I've foolishly suggested to one of them that it could take no longer than the end of next month, so I need to know if I'm likely to have to do some backpedalling on that date.
Thanx,
Rich Megginson wrote:
We hope to have another binary release by the end of the week. We've just got a couple of bug fixes to go.
Hi Rich,
<prod>!
http://directory.fedora.redhat.com/wiki/Download has pointers to new releases (Fedora Directory Server 1.0) but the links all give me 404's.
So are we getting closer to that binary release?
Del wrote:
Rich Megginson wrote:
We hope to have another binary release by the end of the week. We've just got a couple of bug fixes to go.
Hi Rich,
<prod>!
http://directory.fedora.redhat.com/wiki/Download has pointers to new releases (Fedora Directory Server 1.0) but the links all give me 404's.
So are we getting closer to that binary release?
Closer . . .
Richard Megginson wrote:
Del wrote:
Rich Megginson wrote:
We hope to have another binary release by the end of the week. We've just got a couple of bug fixes to go.
Hi Rich,
<prod>!
http://directory.fedora.redhat.com/wiki/Download has pointers to new releases (Fedora Directory Server 1.0) but the links all give me 404's.
So are we getting closer to that binary release?
Closer . . .
You do realize that MD5 has been _fully_ broken now, don't you? And I'm not talking about dictionary attacks; I'm talking about a fast mathematical attack vector on the algorithm itself.
An interesting demonstration here:
http://www.doxpara.com/?q=node&from=10
Collision generators here:
http://www.stachliu.com/collisions.html
The new and improved collision generator:
http://www.stachliu.com/md5coll.c
"Old (Wang, et al.) average run time on IBM P690 supercomputer - 1 hour" - out of reach for most people
"New average run time on P4 1.6ghz PC - 45 minutes" - within reach for nearly everyone
Now, storing md5 doesn't seem much safer than storing crypt.
-- mike
Mike Jackson wrote:
Richard Megginson wrote:
Del wrote:
Rich Megginson wrote:
We hope to have another binary release by the end of the week. We've just got a couple of bug fixes to go.
Hi Rich,
<prod>!
http://directory.fedora.redhat.com/wiki/Download has pointers to new releases (Fedora Directory Server 1.0) but the links all give me 404's.
So are we getting closer to that binary release?
Closer . . .
You do realize that MD5 has been _fully_ broken now, don't you? And I'm not talking about dictionary attacks; I'm talking about a fast mathematical attack vector on the algorithm itself.
An interesting demonstration here:
http://www.doxpara.com/?q=node&from=10
Collision generators here:
http://www.stachliu.com/collisions.html
The new and improved collision generator:
http://www.stachliu.com/md5coll.c
"Old (Wang, et al.) average run time on IBM P690 supercomputer - 1 hour" - out of reach for most people
"New average run time on P4 1.6ghz PC - 45 minutes" - within reach for nearly everyone
Now, storing md5 doesn't seem much safer than storing crypt.
That's why cert based auth is the best way to go. But in the meantime, the next release of FDS will support SHA-256, SHA-384, and SHA-512 password hashing.
-- mike
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
You do realize that MD5 has been _fully_ broken now, don't you? And I'm not talking about dictionary attacks; I'm talking about a fast mathematical attack vector on the algorithm itself.
This isn't really about storing MD5s for any length of time, it's about migrating a bunch of existing MD5 hashes into the directory from another directory that stores them (and doesn't support SSHA-512 or anything similar).
Also, a couple of points:
* The MD5 hashes aren't publically available. To generate a collision on a hash you have to have the hash, and if the server won't let you read the hash then you're stumped. Until, of course, you break the root DN password of the DS, in which case the security of MD5 is the least of your worries.
* The MD5 collision generators can generate (quickly) two strings that have the same MD5 checksum. We cannot (yet) quickly generate a string that has a chosen checksum. Manipulating a piece of data to have the checksum you want (i.e. MD5 password cracking) is a hell of a lot more difficult than finding a colision between two bits of random data. The walls are down on this, though, and generating a piece of data with a chosen checksum is probably a few years away. Long enough to begin and conclude a password migration strategy.
* It's still safer than storing clear text.
389-users@lists.fedoraproject.org