SHA-2 in any form is unsuitable for use as a password hash, simply because it is too easy to compute. At this point the best choice is the one that won the Password Hashing Competition - Argon2. https://github.com/P-H-C/phc-winner-argon2
Patches for adding this to OpenLDAP would of course be welcome. Norman Gray wrote: > > Greetings. > > I've been doing some reading on password hashes, in OpenLDAP and elsewhere. > It's slightly harder to find explicit details about this, than I expected, > and some > of what I learned was unexpected to me, though probably familiar to many on > this list. In the expectation I'm not the only naive one, I'd like to log > these > on-list, with a broad query about whether I'm understanding things correctly. > > There are very good discussions at [1] and [2]. > > SHA-256/SHA-512 on OpenLDAP doesn't mean the same as what is nominally the > same hash function in glibc. In OpenLDAP, the MD5 and SHA-whatever hash of a > password is the result of hashing the password plus salt -- ie, pretty much > what I expected -- but in glibc's crypt(3), the $5$ and $6$ hashes are the > result of > an unspecified number of rounds of such hashing (the $1$/MD5 glibc hash does > appear to be compatible with OpenLDAP {SMD5}, though). (Quite possibly > everyone > else in the world already knew this, but I didn't!) > > While the glibc $5$ and $6$ hashes are therefore, in principle, somewhat > resistant to brute-forcing, the OpenLDAP ones are not, and so should be > managed as > confidential data. > > MD5 _isn't_ significantly worse than plain SHA-whatever for password hashing, > since its discovered defects with respect to collisions are not a problem for > this > application (it's still resistant to 'preimages'). However both are unsafe > for secure password storage, simply because they're too fast (by design), and > MD5 is > unusable simply because 'everyone knows MD5 is broken', so it would require > tedious explanation. > > Thus it would seem that the SHA-2 support optionally available in the > OpenLDAP distribution (in contrib/slapd-modules/passwd/sha2) doesn't actually > benefit me > much, over and above the MD5 and SHA-1 support available by default. However > PBKDF2 (available in contrib/slapd-modules/passwd/pbkdf2) would be usable > immediately, though this appears to be not the best such function available. > > So the two options for password storage seem to be > > * use {SSHA} and -- as [3] stresses -- protect password attributes as if > they were clear text; or > * one way or another use a hash-stretching algorithm such as bcrypt (though > [4] -- *sigh*) or scrypt [5] (maybe the best option?) or PBKDF2 > * (and don't worry about having to protect password attributes?). > > Is that about right? > > Is there a consensus OpenLDAP best practice here? > > Best wishes, > > Norman > > > [1] https://crackstation.net/hashing-security.htm > [2] > https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846 > [3] https://openldap.org/doc/admin24/security.html > [4] https://github.com/wclarie/openldap-bcrypt/issues/1 > [5] https://github.com/Tarsnap/scrypt > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/