Juergen.Sprenger@swisscom.com wrote:
Hi Gerardo,
the 'short strings' You mentioned are 13-character DES password hashes. For security reasons they should not be used anymore if possible.
It's always interesting to see how things have progressed. ~15 years ago a desktop processor could perform 130,000 crypts/second, and could crack a typical 8 character password in ~251 days.
http://personal.stevens.edu/~khockenb/crypt3.html
Skip ahead to 2010 and a single-core desktop processor can do 10 million crypts/second - so your crack time is now down to ~2.5 days for a single password, even less for multi-core. Of course, you can crack an entire password file all in parallel, since you only need to perform a simple comparison of the crypt result with each password.
http://openwall.info/wiki/john/benchmarks
So if all else fails, you can most likely generate the original plaintext for the majority of these old passwords in not much time. Of course, having done that, you probably won't want any of your users to continue using them...
Putting {crypt} in front of them should be sufficient for conversion.
Normalizing the passwords might become difficult if only their DES hashes are available.
Especially in a heterogenous environment using simple authentication together with ssl/tls will prevent some trouble.
In that case OpenLDAP will take care of the crypto algorithm, creation of password hashes and so on while clients just send plaintext passwords over an encrypted ssl/tls connection to the LDAP server.
This will also prevent trouble if there is no common algorithm supported by all OS flavors and releases in Your environment which use LDAP for authentication.