Dear everyone
I am planing to migrate an Intranet info system to authenticate with OpenLDAP, so more of our business can be done with the same login. The old system uses their own SQL table to store user information, no problem, I can write a script to convert to LDIF format. But md5 was used to encrypt user password, and the developer of that system knows md5 is cracked, so he encrypted the md5 hash with md5 method again.
clear text password --> md5 hash --> md5 hash of the md5 hash
My question:
1. Have you ever heard this solution to avoid md5 crack? Now as I cannot reach the original system author, I wonder how this idea come to be (e.g. why not using SHA). 2. Does it work? (is md5 hashed md5 hash much safer with no side-effect?) 3. Now, how we can migrate this system to use openldap. AFAIK openldap have no direct support for such hash. There are a lot of users of the system and there will be problems if migration is done and everyone's password is reset..
Thanks in advance!
Zhang Weiwu wrote:
Dear everyone
I am planing to migrate an Intranet info system to authenticate with OpenLDAP, so more of our business can be done with the same login. The old system uses their own SQL table to store user information, no problem, I can write a script to convert to LDIF format. But md5 was used to encrypt user password, and the developer of that system knows md5 is cracked, so he encrypted the md5 hash with md5 method again.
clear text password --> md5 hash --> md5 hash of the md5 hash
My question:
- Have you ever heard this solution to avoid md5 crack? Now as I cannot reach the original system author, I wonder how this idea come to be (e.g. why not using SHA).
not heard of it.
- Does it work? (is md5 hashed md5 hash much safer with no side-effect?)
Sounds like it would take twice as long.
- Now, how we can migrate this system to use openldap. AFAIK openldap have no direct support for such hash. There are a lot of users of the system and there will be problems if migration is done and everyone's password is reset..
You'd have to get everyone to type in their md5 hash ;-)
You've no choice but to reset all passwords. Seems like the best time to do it under the "migration" umbrella.
Gavin.
Gavin Henry ghenry@suretecsystems.com wrote:
- Now, how we can migrate this system to use openldap. AFAIK openldap have no direct support for such hash. There are a lot of users of the system and there will be problems if migration is done and everyone's password is reset..
You'd have to get everyone to type in their md5 hash ;-)
You've no choice but to reset all passwords. Seems like the best time to do it under the "migration" umbrella.
Alternatively, you can crack your MD5 hashes to recover the password hashes. If that's so easy, it should not be a problem...
I'd agree with Gavin. Just go ahead and reset the passwords. Might be a good time to work on a password self-service solution too. ;)
-- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com
Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices
Identity Management, LDAP, and Linux Integration
Gavin Henry wrote:
Zhang Weiwu wrote:
Dear everyone
I am planing to migrate an Intranet info system to authenticate with OpenLDAP, so more of our business can be done with the same login. The old system uses their own SQL table to store user information, no problem, I can write a script to convert to LDIF format. But md5 was used to encrypt user password, and the developer of that system knows md5 is cracked, so he encrypted the md5 hash with md5 method again.
clear text password --> md5 hash --> md5 hash of the md5 hash
My question:
- Have you ever heard this solution to avoid md5 crack? Now as I cannot reach the original system author, I wonder how this idea come to be (e.g. why not using SHA).
not heard of it.
- Does it work? (is md5 hashed md5 hash much safer with no
side-effect?)
Sounds like it would take twice as long.
- Now, how we can migrate this system to use openldap. AFAIK openldap have no direct support for such hash. There are a lot of users of the system and there will be problems if migration is done and everyone's password is reset..
You'd have to get everyone to type in their md5 hash ;-)
You've no choice but to reset all passwords. Seems like the best time to do it under the "migration" umbrella.
Gavin.
On Oct 10, 2007, at 6:41 PM, Zhang Weiwu wrote:
Dear everyone
I am planing to migrate an Intranet info system to authenticate with OpenLDAP, so more of our business can be done with the same login. The old system uses their own SQL table to store user information, no problem, I can write a script to convert to LDIF format. But md5 was used to encrypt user password, and the developer of that system knows md5 is cracked, so he encrypted the md5 hash with md5 method again.
clear text password --> md5 hash --> md5 hash of the md5 hash
My question:
- Have you ever heard this solution to avoid md5 crack? Now as I cannot reach the original system author, I wonder how this idea come to be (e.g. why not using SHA).
Yes, but generally with more rounds than 2... and often with a salt. It's called key strengthening. (See http://en.wikipedia.org/wiki/Key_strengthening).
- Does it work? (is md5 hashed md5 hash much safer with no side-
effect?)
md5(md5(p)) requires twice as many cycles as md5(p) and hence is a minor hinderance to those attempting dictionary attacks. The more rounds, the greater the hinderance. But without a salt, it's subject to pre-computed dictionary attacks. While it 2*md5 pre-computed dictionaries are likely rare, 1*md5 pre-computed dictionary aren't. And they could be used to save the attacker half the work in cracking a 2*md5 hash.
- Now, how we can migrate this system to use openldap.
Implement a custom hash comparator module.
I would recommend you design it to perform any number of rounds as determined from the value of userPassword. For instance, one could have a value such as {MD5:N}base64encodingOfHash. Then in migrating the data, I'd add some many more rounds, but not too many. One has to balance the server performance requirements with the attack mitigation requirements. Such an approach allows one to add more rounds later on, which is a plus.
For more general purpose, I'd suggest a {SSHA256:N} as a replacement for current set of seeded/unseeded SHA1 and MD5 hash schemes (or possibly s/256/512/). I note that {SMD5:N} or {SSHA1:N} might be useful in environments that have key length restrictions.
AFAIK openldap have no direct support for such hash. There are a
lot of users of the system and there will be problems if migration is done and everyone's password is reset..
Thanks in advance!
-- Real Softservice
Huateng Tower, Unit 1788 Jia 302 3rd area of Jinsong, Chao Yang
Tel: +86 (10) 8773 0650 ext 603 Mobile: 135 9950 2413 http://www.realss.com
openldap-software@openldap.org