...

...

"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%E2%80%91security.htm [2]

https://security.stackexchange.com/questions/211/how%E2%80%91to%E2%80%91secu...

31846#31846 [3] https://openldap.org/doc/admin24/security.html [4] https://github.com/wclarie/openldap%E2%80%91bcrypt/issues/1 [5] https://github.com/Tarsnap/scrypt

‑‑ Norman Gray : https://nxg.me.uk

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-passwo... [3] https://openldap.org/doc/admin24/security.html [4] https://github.com/wclarie/openldap-bcrypt/issues/1 [5] https://github.com/Tarsnap/scrypt