--On Monday, April 29, 2013 3:28 PM -0700 Chris Hiestand chiestand@salk.edu wrote:

Since SSHA-1 is weak these days I'd like to switch to PBKDF2, Bcrypt or the like with key stretching. Since Openldap does not support relatively strong hashes, do you guys use SASL to store stronger hashes? If so, what kind of backend are you using to store hashes?

I would suggest you look at the contrib password module, which supports a number of schemes.

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

On Tue, Apr 30, 2013 at 08:21:30AM +0200, Michael Ströder wrote:

...

--On Monday, April 29, 2013 3:28 PM -0700 Chris Hiestand chiestand@salk.edu wrote:

...

Since SSHA-1 is weak these days I'd like to switch to PBKDF2, Bcrypt or the like with key stretching. Since Openldap does not support relatively strong hashes, do you guys use SASL to store stronger hashes? If so, what kind of backend are you using to store hashes?

To be more precise: One could use the sources in contrib/slapd-modules/passwd/ as a template for implementing PBKDF2, Bcrypt, etc. schemes. There are no such implementations yet.

Much easier: use one of the hash schemes supported by the underlying platform's own crypt library. Most Linux, FreeBSD, OpenBSD, Solaris etc will allow you to use a range of hash functions by specifying the salt format string. The more recent hash formats allow you to choose the number of iterations so that you can tune the algorithm to provide the desired degree of protection against brute-force attacks.

See man crypt(3) on your platform for details of what is supported.

To enable this in slapd.conf add these lines to the global section:

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

The salt format here is '$6$' which invokes a SHA512-based hash method and provides 12 characters (72 bits) of salt. It uses the default 5000 iterations. The table on Hashcat's home page suggests that this is around 50,000 times stronger than the simple SSHA1 hash.

For a slightly stronger hash you might choose bcrypt - introduced by '$2a$' or '$2y$'. Before doing so you should read the description in crypt(3) about bugs in early versions relating to 8-bit hashes.

To make sure that passwords presented as plaintext data in the userPassword attribute get hashed, you should add the Password Policy overlay:

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

... and create a default policy entry something like this:

# 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

BE AWARE that this still only controls passwords set via the LDAP protocol. If you use slapadd to load your data then the database will get exactly what is in the ldif file.

Andrew