[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SHA-2 and other hashes
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/