[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SHA-2 and other hashes
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
--
Norman Gray : https://nxg.me.uk