Hello,
I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users".
Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right?
Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?)
And if this document does mean to say that compare, search, and read access should be denied for directory users' _own_ (self) userPassword attrs, can someone please explain why, if users can read their userPassword, it would be worse for it to be encrypted than plain text?
Many thanks,
Chris Paul Rex Consulting, Inc email: chris.paul@rexconsulting.net web: http://www.rexconsulting.net http://www.rexconsulting.net phone, toll-free: +1 (888) 403-8996 ext 1
On 3/22/21 6:49 PM, Christopher Paul wrote:
I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users".
IMHO this is more a warning regarding the functional model than a security warning.
Because strictly speaking an LDAP client expects the server not to muck with attribute values. To be more clear: If the client writes value 'bar' to attribute 'foo' it expects a search with (foo=bar) to return that entry later. Similar with compare requests.
Wording could be better though.
Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right?
In general access to attribute userPassword should be very restrictive. Only replicas should be granted read access. Account owner (self) should be able to write (not read!) the userPassword value (=w).
There are use-cases where userPassword values are read by an LDAP client for using them as shared secret with challenge-response mechs, e.g. some RADIUS methods. But in these cases passwords are not hashed anyway.
Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?)
Right.
Ciao, Michael.
Christopher Paul chris.paul@rexconsulting.net schrieb am 22.03.2021 um 18:49
in Nachricht a3f5ac1d-d821-933d-0537-f0d50c8ff6b8@rexconsulting.net:
Hello,
I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users".
Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right?
Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?)
And if this document does mean to say that compare, search, and read access should be denied for directory users' _own_ (self) userPassword attrs, can someone please explain why, if users can read their userPassword, it would be worse for it to be encrypted than plain text?
Obviously if you come to some user's terminal that isn't locked, you cannot find outthe user's password normally (nor can you change it), but when readoing the cleartext password you could.
Many thanks,
Chris Paul Rex Consulting, Inc email: chris.paul@rexconsulting.net web: http://www.rexconsulting.net http://www.rexconsulting.net phone, toll-free: +1 (888) 403-8996 ext 1
Michael Ströder michael@stroeder.com schrieb am 22.03.2021 um 19:07 in
Nachricht d2b355b4-0c27-945c-21e4-418ccad1d8ca@stroeder.com:
On 3/22/21 6:49 PM, Christopher Paul wrote:
I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users".
Maybe at that point in the manual there could be a short explanation how password authentication works: Obviously "someone" has to be able to read the password in order to check it. At least all the typical UNIX password checks work like that.
IMHO this is more a warning regarding the functional model than a security warning.
Because strictly speaking an LDAP client expects the server not to muck with attribute values. To be more clear: If the client writes value 'bar' to attribute 'foo' it expects a search with (foo=bar) to return that entry later. Similar with compare requests.
Wording could be better though.
Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right?
In general access to attribute userPassword should be very restrictive. Only replicas should be granted read access. Account owner (self) should be able to write (not read!) the userPassword value (=w).
There are use-cases where userPassword values are read by an LDAP client for using them as shared secret with challenge-response mechs, e.g. some RADIUS methods. But in these cases passwords are not hashed anyway.
Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?)
Right.
Ciao, Michael.
openldap-technical@openldap.org
-
Christopher Paul -
Michael Ströder -
Ulrich Windl