Antw: SHA-2 and other hashes

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> "Norman Gray" <gray@nxg.name> schrieb am 03.06.2019 um 13:08 in Nachricht
<C4EA7171-61EC-4913-BBCD-F29BB9D8546B@nxg.name>:

> 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!)

Hi!

First the number of rounds is NOT unspecified: It
s explicitly specified, it's optional, and (I think) it defaults to one.
Also considering a 16-char one-of-64 salt, even one round for SHA256 should be
strong enough aaginst a rainbowtable of weak passwords. Adding more rounds just
delays guessing weak passwords by some factor (IMHO).
The essence is: /etc/shadow seems to use the 1-round variant, so the
"salt+password" approach seems compatible with openLDAP.

> 
> 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.

See above: The salt is mostly against rainbow tables, while the rounds are
against brute forrce IMHO. As the default shadow seems to use one round, so
this argument lacks the precondition.

(In case you want to try cracking such a password, try
"$6$CM21wofswJzj$H.NfEtuX3m6Hjtx4H0mLq4MID3JqK254DCIw6Sjeh1kmI27DEwcAb8ilxb8KH08PmQIcTD8XloWFAXKmC/uuR1")


> 
> 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