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
"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
Ulrich, hello.
On 3 Jun 2019, at 13:50, Ulrich Windl wrote:
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.
Good point -- the number of rounds is indeed exposed.
If I'm correctly reading crypt/sha256-crypt.c in https://ftp.gnu.org/gnu/glibc/, then the default number of rounds is 5000 and, as you say, the number of rounds can be indicated in a param=value clause in the passwd string (as gestured towards in https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md).
But I may have been unclear: by 'unspecified' I meant 'not described in a formal specification' (as far as I can see), so that I would not be comfortable trying to reimplement the glibc password-hashing process based on documentation alone.
Best wishes,
Norman
Howard, hello.
On 3 Jun 2019, at 15:07, Howard Chu wrote:
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
That makes sense -- thanks.
Patches for adding this to OpenLDAP would of course be welcome.
I'm sure. However I fear I'm not going to be able to oblige in the short term....
Best wishes,
Norman
--On Monday, June 03, 2019 4:07 PM +0100 Howard Chu hyc@symas.com wrote:
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
Work on such a module was started https://www.openldap.org/its/index.cgi/?findid=8575
Unfortunately, never finished.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 6/3/19 4:13 PM, Norman Gray wrote:
If I'm correctly reading crypt/sha256-crypt.c in https://ftp.gnu.org/gnu/glibc/, then the default number of rounds is 5000 and, as you say, the number of rounds can be indicated in a param=value clause in the passwd string (as gestured towards in https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md).
On my system the default of 5000 rounds for sha512crypt ($6$) is documented in crypt(5).
Ciao, Michael.
"Norman Gray" gray@nxg.name schrieb am 03.06.2019 um 16:13 in Nachricht
BFD15D85-2DCE-4E3A-8CF6-04190CD520C4@nxg.name:
Ulrich, hello.
On 3 Jun 2019, at 13:50, Ulrich Windl wrote:
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.
Good point -- the number of rounds is indeed exposed.
If I'm correctly reading crypt/sha256-crypt.c in https://ftp.gnu.org/gnu/glibc/, then the default number of rounds is 5000 and, as you say, the number of rounds can be indicated in a param=value clause in the passwd string (as gestured towards in https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md).
But I may have been unclear: by 'unspecified' I meant 'not described in a formal specification' (as far as I can see), so that I would not be comfortable trying to reimplement the glibc password-hashing process based on documentation alone.
Correct; I read the manual, not the source, nad there the default number of rounds was not mentioned.
Best wishes,
Norman
-- Norman Gray : https://nxg.me.uk
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Norman Gray -
Quanah Gibson-Mount -
Ulrich Windl