Re: SSHA as default password-hash in next password change

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

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
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------