Hi Michael,

Thanks for your prompt reply. We are not using any client..we are just changing the user password from ssh console. We imported our /etc/passwd to openldap and our idea is when the user gets the next expiration time the new password be in SSHA. Is it possible?....

Thanks!

On 06/03/2013 02:39 PM, Michael Ströder wrote:

cbulist@gmail.com wrote:

...

All our users in LDAP database are under MD5 encryption. We want to change this to SSHA in the next user password change. We tried using: password-hash {SSHA} option in slapd.conf and restart the ldap service but it didn't work. The user password are still under MD5 encryption. We are using openldap 2.4.23-26 version.

Directive password-hash only affects Password Modify Extended Operation. So how did you make users change their password? Which client software did you use?

Ciao, Michael.

On Mon, Jun 03, 2013 at 03:54:38PM -0500, cbulist@gmail.com wrote:

We are not using any client..we are just changing the user password from ssh console.

If you use the passwd command, the LDAP operation used to make the change will depend on your PAM LDAP implementation. It might be the Password Modify extended operation (good) or it might be an ordinary LDAP Modify operation (less good).

We imported our /etc/passwd to openldap and our idea is when the user gets the next expiration time the new password be in SSHA. Is it possible?....

To catch both cases above you will need to add an overlay to your slapd config. First set the desired hash in the global section:

password-hash {SSHA}

Then add an overlay on top of the main database section:

overlay ppolicy ppolicy_default "cn=Password Policy,dc=dir,dc=example,dc=org" ppolicy_hash_cleartext

You should also create the password policy entry, something like this:

# Default password policy # Applies to userPassword (2.5.4.35) dn: cn=Password Policy,dc=dir,dc=example,dc=org objectClass: organizationalRole objectClass: pwdPolicy cn: Password Policy description: The default password policy pwdAttribute: 2.5.4.35 pwdLockout: TRUE

The overall effect will be that passwords that arrive at the LDAP server in plain text will be hashed using the SSHA scheme. Any passwords that arrived pre-hashed (e.g. by PAM LDAP) will be stored as-is (it is not possible to convert from one hash scheme to another).

Why are you changing from MD5 to SSHA? If it is to improve password security you may be disappointed, depending on which MD5-based hash you currently use. As the passwords came from an /etc/passwd file it is likely that they use the $6$ or $2a$ hash schemes. Those are both vastly more secure than {SSHA} against brute-force attacks. The known weaknesses in the MD5 algorithm are much less significant than the fact that {SSHA} only runs the algorithm *once* whereas $6$ and $2a$ are carefully designed to be slow to calculate.

For an indication of the relative strengths of various hash schemes, see Hashcat: http://hashcat.net/oclhashcat-plus/ (table near the bottom of the page).

If all your LDAP servers will run on Linux, Solaris, or similar OS then you can stay with $6$ like this:

password-hash {CRYPT} password-crypt-salt-format "$6$%.12s"

The result will be about 60,000 times harder to break than SSHA.

Andrew

On Tue, Jun 04, 2013 at 10:49:27PM -0500, cbulist@gmail.com wrote:

We are already using overlay and it is working perfectly. Your point about MD5 is great!...but we have some requirements and the idea is use SSHA-512 for our password. I read some post from Michael talking about this problem and I know that there is a contrib module for SSHA-512.

It all depends on what you are protecting against and what you have to interwork with. The high-profile risk for most organisations is the theft of large numbers of username-password pairs, so I tend to focus on mitigating that risk.

...

For an indication of the relative strengths of various hash schemes, see Hashcat: http://hashcat.net/oclhashcat-plus/ (table near the bottom of the page).

On the basis of that table, SSHA-512 will gain you about a factor of 10 protection over SSHA1. A single PC with a mid-range graphics card can still try about 70,000,000 password guesses per second.

Remember that MD5 and the SHA series were designed to be *fast*. This is exactly the opposite of what you want when protecting passwords, so password hash schemes have to use delaying tactics on top.

...

If all your LDAP servers will run on Linux, Solaris, or similar OS then you can stay with $6$ like this:

password-hash {CRYPT} password-crypt-salt-format "$6$%.12s"

The result will be about 60,000 times harder to break than SSHA.

The $6$ hash uses SHA512, but does it many times. The effect is to reduce that single PC's attack rate to nearer 12,000 guesses per second. If your LDAP database gets compromised or someone steals your backup tapes then that extra protection could be very valuable.

Andrew