I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously.
Is there an approach to preventing a brute force attack at guessing an entry's password? I've noticed that with my configuration, when performing an ldapwhoami or ldapsearch, and when submitting an incorrect password, I receive an immediate response that the password is bad, rather than a delay which I would like to have.
I'm using version 2.3.39.
In other words, this is what I get today:
~# time ldapsearch -Y DIGEST-MD5 -U abrown@olp.net -w badpassword SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated
real 0m0.015s user 0m0.012s sys 0m0.004s
But I'd like to enforce a server side delay of, for example, 5 seconds.
I understand that I could implement the password policy overlay to temporarily lockout an account once it's reached a certain number of bad password attempts, but I believe that only applies to simple (-x) binds. Is that correct?
Thanks, - Dan White
Dan White writes:
I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously. (...) But I'd like to enforce a server side delay of, for example, 5 seconds.
Several seconds' delay? Your users would murder you. Except the ones who didn't know LDAP already and just concluded that LDAP is crap.
I understand that I could implement the password policy overlay to temporarily lockout an account once it's reached a certain number of bad password attempts, but I believe that only applies to simple (-x) binds. Is that correct?
Don't know, but the manpage doesn't mention "simple", only "bind".
Hallvard B Furuseth wrote:
Dan White writes:
I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously. (...) But I'd like to enforce a server side delay of, for example, 5 seconds.
Several seconds' delay? Your users would murder you. Except the ones who didn't know LDAP already and just concluded that LDAP is crap.
User-friendliness aside, have a look at slapo-retcode.
But I'd like to enforce a server side delay of, for example, 5 seconds.
User-friendliness aside, have a look at slapo-retcode.
Probably the right points -- but we all know what's more important than the users, let's think about *admin* friendliness. I'd like to believe that my servers are roughly "right-sized", but that means fractional-second response times. If I started putting even a small amount of those connections onto 5 second sleeps, things would get very bad in very short order. This assumes no malice, just the very-very-very regular batch of users with typos; I'd hate to think how bad this could get under the active attack you envision.
I suppose you could make your overlay do something heinous like drop the connection. But never allowing err=49 (or, much worse, disclosing information by *sometimes* err=49) seems like it would produce other forms of pain.
Hallvard B Furuseth wrote:
Dan White writes:
I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously. (...) But I'd like to enforce a server side delay of, for example, 5 seconds.
Several seconds' delay? Your users would murder you. Except the ones who didn't know LDAP already and just concluded that LDAP is crap.
I'd only want a delay when a user/attacker has entered a bad password, similar to the way a UNIX shell introduces a delay. My concern is that the faster I tune my server, the more likely it will become that an attacker will brute force a password.
Don't know, but the manpage doesn't mention "simple", only "bind".
I've seen mention on the list before that ppolicy does not apply to SASL binds, and that's been my experience in testing as well.
- Dan
Howard Chu wrote:
Hallvard B Furuseth wrote:
Dan White writes:
I'm planning on allowing public access to my OpenLDAP server for address book access. I'm only planning to allow authenticated access, both via simple binds and SASL binds, not anonymously. (...) But I'd like to enforce a server side delay of, for example, 5 seconds.
Several seconds' delay? Your users would murder you. Except the ones who didn't know LDAP already and just concluded that LDAP is crap.
User-friendliness aside, have a look at slapo-retcode.
Thanks Howard, I'll check it out.
- Dan
Dan White wrote:
I'd only want a delay when a user/attacker has entered a bad password, similar to the way a UNIX shell introduces a delay. My concern is that the faster I tune my server, the more likely it will become that an attacker will brute force a password.
Given the current implementation, the delay will keep a thread busy for its duration. Your server, under attack, would quickly become unresponsive for any user. Probably, your case should be handled separately, e.g. by writing an overlay that registers a delay for a given connection and quicly releases the operation, and a background thread that wakes up when it's time to return errors after the delay. Nothing dramatic, but definitely needs some development.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Given the current implementation, the delay will keep a thread busy for its duration. Your server, under attack, would quickly become unresponsive for any user. Probably, your case should be handled separately, e.g. by writing an overlay that registers a delay for a given connection and quicly releases the operation, and a background thread that wakes up when it's time to return errors after the delay. Nothing dramatic, but definitely needs some development.
A bit trickier than that; it should not immediately release the operation either. Otherwise you can build up quite a long queue of pending Bind responses if they submit multiple Bind requests blindly. I.e., you also need to prevent the connection from accepting more operations while a delay is in effect.
Dan White skrev, on 07-02-2008 18:42:
[...]
I understand that I could implement the password policy overlay to temporarily lockout an account once it's reached a certain number of bad password attempts, but I believe that only applies to simple (-x) binds. Is that correct?
My site's running ppolicy on 2.3 on Linux for gdm logins with great success; however, my understanding is, that it only cares about pam/pam_exop calls (presumably also similar from dedicated client or proxy software). Looking at the relevant operational attributes in gq, one can see that each failed login is recorded tn the pwdFailureTime attribute. Doing a repeated ldapsearch -x on an account with an invalid password doesn't make the blindest bit of difference to this attribute and multiple failed attempts are allowed.
I've also wanted what you want but refuse to publish site email addresses on the Internet to all and sundry. At the moment authorized users can obtain site-specific info by logging into webmail, which uses LDAP internally.
Best,
--Tonni
On Thursday 07 February 2008 21:37:20 Dan White wrote:
I'd only want a delay when a user/attacker has entered a bad password, similar to the way a UNIX shell introduces a delay.
The UNIX shell (well actually, the login binary on my UNIX clone OS, which uses PAM) doesn't introduce a delay for a bad password, but under any circumstance where the credentials supplied are incorrect.
Implementing it only for when the password is incorrect is typically discouraged by security researchers, as this is information disclosure (which could assist an attacker in gathering information for performing an attack). For example, a few years back, OpenSSH specifically added a patch to ensure that when OpenSSH authenticated via PAM, that the delay would be exactly the same whether the user existed or not.
Now, if you really want to introduce a long delay when any bind fails, I think you will experience problems.
My concern is that the faster I tune my server, the more likely it will become that an attacker will brute force a password.
IMHO, you should rather ensure that entering the incorrect password more than a specified number of times results in the account being locked out. If your SASL mechanism can't do this, take that to their list.
Don't know, but the manpage doesn't mention "simple", only "bind".
I've seen mention on the list before that ppolicy does not apply to SASL binds, and that's been my experience in testing as well.
Naturally, as the p in ppolicy is for password, in the SASL case, the LDAP server doesn't have the password (in most cases). However, for the simple bind case, I would use ppolicy with lockout.
But then, I authenticate 200 users/second, and I can't tolerate delays or more connection build-up.
Regards, Buchan
On Friday 08 February 2008 08:11:58 Tony Earnshaw wrote:
Dan White skrev, on 07-02-2008 18:42:
[...]
I understand that I could implement the password policy overlay to temporarily lockout an account once it's reached a certain number of bad password attempts, but I believe that only applies to simple (-x) binds. Is that correct?
My site's running ppolicy on 2.3 on Linux for gdm logins with great success; however, my understanding is, that it only cares about pam/pam_exop calls (presumably also similar from dedicated client or proxy software).
exop only affects how passwords are changed, not what the client sends on a simple bind request.
Looking at the relevant operational attributes in gq, one can see that each failed login is recorded tn the pwdFailureTime attribute. Doing a repeated ldapsearch -x on an account with an invalid password doesn't make the blindest bit of difference to this attribute and multiple failed attempts are allowed.
Uh, when binding as the DN in question, or not (your ldapsearch -x is ambiguous)?
In the testing I did a while back (where I used ldapwhoami), simple binds with and without the ppolicy control both resulted in lockout (but the one with the control would warn about impending expiry when testing expiry). In fact, I broke replication on one of the dev slaves that was using a simple bind in the syncrepl configuration.
Regards, Buchan
Buchan Milne wrote:
The UNIX shell (well actually, the login binary on my UNIX clone OS, which uses PAM) doesn't introduce a delay for a bad password, but under any circumstance where the credentials supplied are incorrect.
Implementing it only for when the password is incorrect is typically discouraged by security researchers, as this is information disclosure (which could assist an attacker in gathering information for performing an attack). For example, a few years back, OpenSSH specifically added a patch to ensure that when OpenSSH authenticated via PAM, that the delay would be exactly the same whether the user existed or not.
Now, if you really want to introduce a long delay when any bind fails, I think you will experience problems.
I think maybe the UNIX shell example was a bad one. I'm an ISP admin, and what I'd like to do is make our LDAP server another ISP service. Today most, if not all, of our ISP services introduce a delay when incorrect *credentials* are supplied (point taken).
For example, all of these services introduce a delay when there's a bad username/password submitted:
POP3 (cyrus) IMAP (cyrus) SMTP (postfix) ftp (vsftp) ssh/scp/sftp
Even in the case where I'm authenticating via SASL (IMAP), I get a delay when I submit incorrect credentials:
neo:~# time echo "a01 logout" | imtest -m DIGEST-MD5 -a baduser -w badpass neo.olp.net <cut> Authentication failed. generic failure Security strength factor: 128 C: Q01 LOGOUT * BYE LOGOUT received a01 OK Completed Connection closed.
real 0m3.154s user 0m0.008s sys 0m0.004s
I do understand there's a difference between protocols, and what effect delays would have for different services, but I'm prepared to accept the performance penalties associated with adding a delay as long as its reasonable.
IMHO, you should rather ensure that entering the incorrect password more than a specified number of times results in the account being locked out. If your SASL mechanism can't do this, take that to their list.
I don't agree that this is a SASL (cyrus) specific issue, since some other services have implemented a delay. I still need to check out the retcode plugin.
Although It'd be interesting if cyrus sasl had some kind of plugin (like canonuser) that could be used to insert some logic during each and every login attempt. I have delays with my pop3/imap/smtp services for incorrect credentials, but I'd love to have a more configurable password policy.
- Dan
openldap-software@openldap.org
-
Aaron Richton -
Buchan Milne -
Dan White -
Hallvard B Furuseth -
Howard Chu -
Pierangelo Masarati -
Tony Earnshaw