--On Tuesday, January 7, 2020 11:52 AM -0800 rammohan ganapavarapu rammohanganap@gmail.com wrote:
Quanah,
Thanks for the quick reply, is there any plans to make SSHA512 default?
No. As I said, SHA1 is mandated by RFC.
also is there any migration steps to move from SHA-1 to SSHA512 ?
After deploying the sha2 module, all users must change their password so the hash gets updated. There is no way to magically convert existing hashes from SSHA1 to another scheme.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, January 7, 2020 10:33 PM +0100 Michael Ströder michael@stroeder.com wrote:
On 1/7/20 9:22 PM, Quanah Gibson-Mount wrote:
No. As I said, SHA1 is mandated by RFC.
Which RFC are you referring to?
https://tools.ietf.org/html/rfc3112
4. Implementation Issues
Servers that support simple bind MUST support the SHA1 scheme and SHOULD support the MD5 scheme.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 1/7/20 10:47 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 7, 2020 10:33 PM +0100 Michael Ströder michael@stroeder.com wrote:
On 1/7/20 9:22 PM, Quanah Gibson-Mount wrote:
No. As I said, SHA1 is mandated by RFC.
Which RFC are you referring to?
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Ciao, Michael.
Probably it's time to consider the deprecation of SHA1
Il mar 7 gen 2020, 23:28 Michael Ströder michael@stroeder.com ha scritto:
On 1/7/20 10:47 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 7, 2020 10:33 PM +0100 Michael Ströder michael@stroeder.com wrote:
On 1/7/20 9:22 PM, Quanah Gibson-Mount wrote:
No. As I said, SHA1 is mandated by RFC.
Which RFC are you referring to?
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Ciao, Michael.
--On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder michael@stroeder.com wrote:
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Incorrect, it's clearly implemented in slapd. Whether it's enabled is a different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;)
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Il 08/01/20 03:05, Quanah Gibson-Mount ha scritto:
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
But in the current version it better to use the contrib module, or delegate the hashing to the C library? I'm currently using on new install:
password-hash {CRYPT} password-crypt-salt-format "$6$%.16s"
but I'm using only Linux, I don't know if this is applicable on other OS.
Simone
--On Wednesday, January 8, 2020 10:27 AM +0100 Simone Piccardi piccardi@truelite.it wrote:
Il 08/01/20 03:05, Quanah Gibson-Mount ha scritto:
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
But in the current version it better to use the contrib module, or delegate the hashing to the C library? I'm currently using on new install:
password-hash {CRYPT} password-crypt-salt-format "$6$%.16s"
but I'm using only Linux, I don't know if this is applicable on other OS.
The use of CRYPT may be non-portable. In addition to the SSHA2 password module, there's a module on github that allows the use of bcrypt:
https://github.com/wclarie/openldap-bcrypt/
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Tue, Jan 07, 2020 at 12:22:05 -0800, Quanah Gibson-Mount wrote:
After deploying the sha2 module, all users must change their password so the hash gets updated. There is no way to magically convert existing hashes from SSHA1 to another scheme.
A controversial solution, but slapd could re-hash the password after a succesful authentication.
Geert
On 1/8/20 10:27 AM, Simone Piccardi wrote:
But in the current version it better to use the contrib module, or delegate the hashing to the C library? I'm currently using on new install:
password-hash {CRYPT} password-crypt-salt-format "$6$%.16s"
but I'm using only Linux, I don't know if this is applicable on other OS.
You can improve this a bit by setting more hashing rounds (default is 5000):
$6$rounds=90000$%.16s
It's worth to read the hints in crypt(5):
"[..] Supported on Linux but not common elsewhere. Acceptable for new hashes. The default CPU time cost parameter is 5000, which is too low for modern hardware."
So as long as you're only using Linux it's fine. But if you want to migrate to other Unix-like OS or Windows these hashes won't work anymore.
Ciao, Michael.
Giuseppe De Marco giuseppe.demarco@unical.it schrieb am 07.01.2020 um
23:53 in Nachricht CABms+Yrhi7PkwV2z99T5W3i6D2jpbo8s8=GESTLYyXb5mh8jdg@mail.gmail.com:
Probably it's time to consider the deprecation of SHA1
The question is how much existing OSes would be impressed by that, meaning: If the OS can only handle SHA1, it does not help declaring it obsolete...
Il mar 7 gen 2020, 23:28 Michael Ströder michael@stroeder.com ha scritto:
On 1/7/20 10:47 PM, Quanah Gibson-Mount wrote:
--On Tuesday, January 7, 2020 10:33 PM +0100 Michael Ströder michael@stroeder.com wrote:
On 1/7/20 9:22 PM, Quanah Gibson-Mount wrote:
No. As I said, SHA1 is mandated by RFC.
Which RFC are you referring to?
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Ciao, Michael.
Quanah Gibson-Mount quanah@symas.com schrieb am 08.01.2020 um 03:05 in
Nachricht <CA17B510ABD069A7884B759C@[192.168.1.144]>:
--On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder michael@stroeder.com wrote:
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Incorrect, it's clearly implemented in slapd. Whether it's enabled is a different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;)
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
Is a "well-salted" SHA-1 really worse than a "poorely-salted" SHA-256? Isn't it all aboput the number of bits that have to be checked (brute-force)?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, January 13, 2020 12:07 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Giuseppe De Marco giuseppe.demarco@unical.it schrieb am 07.01.2020 um
23:53 in Nachricht CABms+Yrhi7PkwV2z99T5W3i6D2jpbo8s8=GESTLYyXb5mh8jdg@mail.gmail.com:
Probably it's time to consider the deprecation of SHA1
The question is how much existing OSes would be impressed by that, meaning: If the OS can only handle SHA1, it does not help declaring it obsolete...
The OS is completely and utterly irrelvant to the discussion. It has no knowledge of the internal hashing mechanism used by OpenLDAP.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Monday, January 13, 2020 12:09 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 08.01.2020 um 03:05 in
Nachricht <CA17B510ABD069A7884B759C@[192.168.1.144]>:
--On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder michael@stroeder.com wrote:
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Incorrect, it's clearly implemented in slapd. Whether it's enabled is a different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;)
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
Is a "well-salted" SHA-1 really worse than a "poorely-salted" SHA-256? Isn't it all aboput the number of bits that have to be checked (brute-force)?
As Howard already noted, what we're looking for is something like Argon2, not further SSHA derivatives.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 13.01.2020 um 17:14 in
Nachricht <071D2235949B1A9339670C6A@[192.168.1.144]>:
‑‑On Monday, January 13, 2020 12:07 PM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
Giuseppe De Marco giuseppe.demarco@unical.it schrieb am 07.01.2020 um
23:53 in Nachricht CABms+Yrhi7PkwV2z99T5W3i6D2jpbo8s8=GESTLYyXb5mh8jdg@mail.gmail.com:
https://sha%E2%80%91mbles.github.io/
Probably it's time to consider the deprecation of SHA1
The question is how much existing OSes would be impressed by that, meaning: If the OS can only handle SHA1, it does not help declaring it obsolete...
The OS is completely and utterly irrelvant to the discussion. It has no knowledge of the internal hashing mechanism used by OpenLDAP.
So you are assuming all systems are using the extended operation to authenticate? Acually I've see code that reads the LDAP user's password and then "combines" that with a password the user has entered. In the former case the password encoding matters. I'm not saying the pattern is good, but I've seen it.
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 13.01.2020 um 17:15 in
Nachricht <A3800A014D08046DDE90E71C@[192.168.1.144]>:
--On Monday, January 13, 2020 12:09 PM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 08.01.2020 um 03:05 in
Nachricht <CA17B510ABD069A7884B759C@[192.168.1.144]>:
--On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder michael@stroeder.com wrote:
AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider this to be rather irrelevant here.
Incorrect, it's clearly implemented in slapd. Whether it's enabled is a different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;)
In any case, I've been advocating for several years now to get rid of SSHA as the default hashing mechanism and replace it with something that may actually have some security value.
Is a "well-salted" SHA-1 really worse than a "poorely-salted" SHA-256? Isn't it all aboput the number of bits that have to be checked (brute-force)?
As Howard already noted, what we're looking for is something like Argon2, not further SSHA derivatives.
There may be a security benefit like going from paranoid to triple paranoid, but for real life I think users' poor passwords and the handling of those (keeping them in unsafe memory, fishing, post-it stickers, etc.) gives real attackers easier means go "get the password".
Regards, Ulrich
--On Tuesday, January 14, 2020 9:08 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
The OS is completely and utterly irrelvant to the discussion. It has no knowledge of the internal hashing mechanism used by OpenLDAP.
So you are assuming all systems are using the extended operation to authenticate? Acually I've see code that reads the LDAP user's password and then "combines" that with a password the user has entered. In the former case the password encoding matters. I'm not saying the pattern is good, but I've seen it.
Then the application is dependent on clear text passwords, not hashed passwords, and again is irrelevant to this discussion.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, January 14, 2020 9:12 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
As Howard already noted, what we're looking for is something like Argon2, not further SSHA derivatives.
There may be a security benefit like going from paranoid to triple paranoid, but for real life I think users' poor passwords and the handling of those (keeping them in unsafe memory, fishing, post-it stickers, etc.) gives real attackers easier means go "get the password".
The OpenLDAP Foundation can only take responsibility for its software, not user habits. Security of the software it provides is a project priority.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 14.01.2020 um 17:01 in
Nachricht <AF994E73E7CA71E6735A3267@[192.168.1.144]>:
‑‑On Tuesday, January 14, 2020 9:08 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
The OS is completely and utterly irrelvant to the discussion. It has no knowledge of the internal hashing mechanism used by OpenLDAP.
So you are assuming all systems are using the extended operation to authenticate? Acually I've see code that reads the LDAP user's password and then "combines" that with a password the user has entered. In the former case the password encoding matters. I'm not saying the pattern is good, but I've seen it.
Then the application is dependent on clear text passwords, not hashed passwords, and again is irrelevant to this discussion.
If it were cleartext, there would not be issues with the hash algorithm used IMHO. No, we were talking about SSHA and sucessors.
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, January 15, 2020 8:00 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Then the application is dependent on clear text passwords, not hashed passwords, and again is irrelevant to this discussion.
If it were cleartext, there would not be issues with the hash algorithm used IMHO. No, we were talking about SSHA and sucessors.
Then any such application is bound to fail now, as people are already free (and already do) use other mechansisms than SSHA to hash their passwords with LDAP. Also, such an application again has zero to do with the OS, which was your contention to start with.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Geert Hendrickx -
Giuseppe De Marco -
Michael Ströder -
Quanah Gibson-Mount -
Simone Piccardi -
Ulrich Windl