Saturday, May 30, 2009

LDAP password policy - how I learned to stop worrying..

I have had to live through implementing a controversial password rotation policy at Mozilla. We had some bitter battles along the lines of "you dimwits, it doesn't do anything for security", and "you are a Nazi for trying to make me change my password so often". While I am still firmly in the "it's a good thing" camp, we have found OpenLDAP's support for password policy somewhat lacking. In particular, it does not distinguish between a few brain dead applications failing multiple times with a single incorrect password and a crack attempt with different incorrect passwords. I tried bringing it up in their mailing lists, but that thread didn't get too far. We have an its request on file as well. At this point, I wimped out and outsourced the problem. Enter Zytrax and the awesome Ron Aitchison, I can't recommend his "OpenLDAP - here is what all this gobbledegook means" guide enough. Jeff Clowser, Ron and I fleshed out the details in the spec and I am now happy to announce that we have patches that work against 2.4.11 and 2.4.16. It's been running on our servers for a few days now and seems to be holding up okay.

Here is how it works. The patch introduces a new attribute - pwdMaxTotalAttempts. Quoting from the README, 'The attribute may take one of three values. If pwdMaxTotalAttempts is zero (0) or not defined then no repeat password checking is perfomed. If pwdMaxTotalAttempts is -1 repeat password checking is performed and an unlimited number of attempts with any number (up to the limit defined by pwdMaxFailure) of repeat passwords are allowed'.

To disable this new behavior you don't have to do anything (i.e. pwdMaxTotalAttempts is not even defined). Also, explicitly setting pwdMaxTotalAttempts to 0 disables it. If you set it to -1, the new policy is enabled and repeat password attempts are tracked. Setting it to a positive number enables the policy as well, but also gives you some limited DoS protection. There are some risks to enabling the new module - it keeps track of your failed passwords (as SSHA hashes). So, proceed with caution when you enable the module.

HTH someone out in the ether.

7 comments:

  1. Just out of curiousity, what are the arguements in favour of forcing users to change passwords often?

    I hate this policy, and have frequently had to resort to numbered passwords ("normalpass1", "normalpass2", etc.), and once had to resort to writing my password on post-notes by my desk when the password program actually checked for common substrings in previous passwords and refused to let me use my numbering system.

    I can't think of any realistic security benefit from the policy.

    ReplyDelete
  2. That's a whole can of worms. I can only point you to stuff I have researched on the topic. You are right in that users using a scheme like that negate the benefits from the policy. The hope is that users will not do that if you make the policy sufficiently usable. Things like allowing pass phrases instead of passwords help. Here is my take - quoted from our internal discussions.
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    The threat we are trying to guard against is that of a leaked or compromised password staying valid for a while. Changing this password every so often mitigates that threat. I am open to proposals that are effective in mitigating this. Why 90 days (why not 6 months, why not a year)? - that's just my take from reading a bunch of online articles and policy recommendations.

    The other threat is that of trying to brute force a stolen password hash file. Our hashes are stored in LDAP and its unlikely someone would gain access to them, but the threat does exist. This link (http://www.lockdown.co.uk/?pg=combi) gives a rough estimate of how long it would take somebody to figure out the original password. From that page, a class D system working on a 96 character space with an 8 char password length would take about 87 days to crack it.

    Finally, a lot more people have spent many more hours (than me) to look into this stuff and have published guidelines on this topic.
    Here are some of their recommendations.

    http://www.sans.org/resources/policies/Password_Policy.pdf
    http://technet.microsoft.com/en-us/library/cc784090.aspx
    http://www.nccs.nasa.gov/policies/passwd.html

    Also, NIST publishes a FDCC document as a guideline for general computing. Note, that these are not guidelines for security sensitive environments, but general desktop guidelines. They suggest a minimum 12 character password, rotated every 60 days.

    http://nvd.nist.gov/fdcc/fdcc_faqs_20070731.cfm

    I am aware that Bruce Schneier and other experts disagree, but I'd rather err on the side of caution.

    ReplyDelete
  3. Do you know if this patch is still maintained anywhere?

    ReplyDelete
    Replies
    1. nope, I haven't been maintaining it - nor am I aware of others maintaining it. I haven't kept track of the OpenLDAP internal changes in the recent releases.

      Delete
    2. Thanks... It's quite surprising (and frustrating) that this simple issue keeps being overlooked by OpenLDAP. Now I'm hitting the same problem you describe and I have no sane way to keep users who change their passwords from locking themselves out.

      Delete
    3. Yeah.. it was a huge pita for us at the time. You might want to try applying those patches against the modern OpenLDAP releases and see if it applies cleanly. Chances are, it won't. If the guts of it are still similar, you might be able to patch it slightly and make it work.

      Delete
    4. Oh yeah, that's the first thing I tried =). What worries me is that I'm using standard openldap packages and compiling my own version will force me choose between redoing the work every time there's a security patch or excluding openldap from updates.

      Thanks again Aravind.

      Delete