Hello
I would like to test if an attribute is set without disclosing it. Using an ACL that grants the search right does it: I can do ldapsearch -b dn attr=*' dn and see if I get a result.
Problem: it is still possible to brute force the atribute value, by searching x* with x being the first lette,r, then xy* and so on.
Is there a way to address this?
On 2016-08-11 14:13, Emmanuel Dreyfus wrote:
I would like to test if an attribute is set without disclosing it. Using an ACL that grants the search right does it: I can do ldapsearch -b dn attr=*' dn and see if I get a result.
Problem: it is still possible to brute force the atribute value, by searching x* with x being the first lette,r, then xy* and so on.
Is there a way to address this?
I don't know your schema, attribute values and requirements. If it's a custom attribute type disabled the SUBSTR matching rule is the only solution in case of DirectoryString or IA5String syntax.
And same issue if attribute type declaration in the schema allows ORDERING searches...
Ciao, Michael.
On 11. aug. 2016 14:36, Michael Ströder wrote:
On 2016-08-11 14:13, Emmanuel Dreyfus wrote:
I would like to test if an attribute is set without disclosing it. Using an ACL that grants the search right does it: I can do ldapsearch -b dn attr=*' dn and see if I get a result.
Problem: it is still possible to brute force the atribute value, by searching x* with x being the first lette,r, then xy* and so on.
(...)
I don't see how to avoid that. There is a DISCLOSE access level, but that's for what to disclose in error situations. I think I'd maintain a separate attribute which is TRUE if the original attribute exists.
And same issue if attribute type declaration in the schema allows ORDERING searches...
Good point, and extended filters can do that without ORDERING in the attrtype definition.
$ ldapsearch -LLLxh ldap.uio.no -b dc=uio,dc=no -s base \ '(labeledURI:CaseIgnoreOrderingMatch:=N)' labeledURI dn: dc=uio,dc=no labeledURI: http://www.uio.no/
On 2016-08-11 14:56, Hallvard Breien Furuseth wrote:
and extended filters can do that without ORDERING in the attrtype definition.
Good point.
To deal with brute-force attempts you have to establish central logging with appropriate log watchers which alarm you in case of a brute-force attack.
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote:
To deal with brute-force attempts you have to establish central logging with appropriate log watchers which alarm you in case of a brute-force attack.
What about this line of defense?
overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*\()?secret=[^\)]*(\).*)?" "$1secret=*$2"
This turns any search filter against the secret attribute into * in order to thwart brute force attempt. Used with a search level ACL, this will cause the server will only reveal if the attribute is present or not.
I gave it a try and it seems to work. Any comment?
An improvement would be to exempt some users (a group) from this rule. Any idea how I can do that?
openldap-technical@openldap.org
-
Emmanuel Dreyfus -
Hallvard Breien Furuseth -
manu＠netbsd.org
-
Michael Ströder