Sign In

Communications of the ACM


Password Policies Are Getting Out of Control

View as: Print Mobile App Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
Carnegie Mellon Associate Professor Jason Hong

 Something I learned a long time ago is that one person's inefficiency is someone else's bottom line. This simple observation explains a lot of the big problems we're facing worldwide. Rather than getting into a discussion of those thorny political topics, however, I want to use this observation as a starting point for discussing something that plagues us all: password policies.

In fact, I think I have found the most difficult password policy in existence today. It was a US government web site, of course. Here were the password policies the site had in place:
  • Password Rules: Minimum 8 characters
  • Must contain at least 1 capital letter
  • Must contain at least 1 lower case letter
  • Must contain at least 1 number
  • Must contain at least 1 special character
  • Cannot contain consecutive characters (abc or cba)
  • Cannot contain repeating characters (aa, bb, etc)
  • Cannot contain the same character more than twice
  • Entered password must be different from last 10 passwords used
  • Cannot be changed within 24 hours
It actually took me about a dozen tries to create a password that covered all of the critera, plus was something I had a chance of remembering. Here are examples of passwords that failed:
  • My_P@$$w0rd   (failed because of repeating characters)
  • !USg0v8   (failed because too short)
  • $tuPidP@55   (failed because repeating characters)
  • 77pasS@77   (failed because same character more than twice)
I even tried a few randomly generated passwords, guaranteed to be strong passwords, which also failed some of the required criteria.
Of course, this password expires after 60 days (on a site that I only need to use every 90 days, no less). And when it did expire, it only took me an extra 15 minutes to figure out who to call to reset the password, plus a 13 minute hold, before my password was finally reset. 
Makes one wonder how much real security is actually being offered with such measures, especially given the costs of staffing a help desk and the wasted time to end-users of having to get their passwords reset.
Why do web sites have such stringent password policies? 
It all comes back to the opening statement: your inefficiency is someone else's bottom line. In a lot of organizations, there is an individual whose role is to keep computing systems secure. They are the people who get yelled at when things go wrong and whose job is on the line. In extreme cases, it becomes fully rational behavior to keep increasing security, no matter what the cost is for end-users, regardless of whether it is effective or not in practice. (Replace the words "computing systems" with "air travel" and we have a decent explanation for the challenges that TSA faces.)
In fact, a 2010 paper by Dinei Florencio and Cormac Herley, two researchers at Microsoft Research, presented an analysis of password policies of 75 different web sites. They found that, almost counterintuitively, "[s]ome of the largest, highest value and most attacked sites on the Internet such as Paypal, Amazon and Fidelity Investments allow relatively weak passwords," primarily because these web sites earn revenue by having people login.
In contrast, it was government and university sites that tended to have stricter (and less usable) policies. They explained these results by arguing that "[t]he reason lies not in greater security requirements, but in greater insulation from the consequences of poor 
usability. Most organizations have security professionals who demand stronger policies, but only some have usability imperatives strong enough to push back. When the voices that advocate for usability are absent or weak, security measures become needlessly 
Unfortunately, there aren't a lot of ways forward here. Passwords are cheap and pervasive, and aren't going away anytime soon. Forcing all members of Congress and all Generals to personally experience the joy of using these web sites themselves also isn't realistic, even if highly desirable. 
In the long-term, we need more ways of getting the incentives of all stakeholders better aligned. Putting helpdesk costs and information security costs under the same budget and under the same person is a good start, as it would force people to think more about the relative costs and benefits of a security policy. Having customer satisfaction be part of the performance metrics for information security folks would also help. 
In the meanwhile, until usability thinking and holistic thinking become more pervasive in computer security, the rest of us will just have to keep suffering the pains of stricter password policies.



Thank you, Thank you, Thank YOU! The idiots in State Government need to read this!


Mordac lives!

Porter Coggins

one point not yet made regarding the type of password character forcing is the loss of entropy. that is, the probability of an 8 character password of all lower case letters of the english alphabet is 26^8. the probability of an 8 char password of both upper and lower case is 52^8, (hang with me, i am driving to the point), the probability of upper and lower case and digits 0 - 9 is 62^8. BUT, each time you force a character, you REDUCE the probability of any particular character by some factor because a character now has a reduced set of possible choices. so, let's say that we are being forced to 8 characters with the constraints: 1 upper, 1 lower, 1 digit, one special (from a set of 10). then the probability of any particular 8 char password is 72x71x70x69x68^4 which is way less than 72^8. now, add the further constraints of no repeat chars, etc, and rather than increasing entropy, password entropy under these constraints reduce entropy and hence make password guessing by brute force much easier. so, forcing only creates weaker passwords rather than opening up the character set for all possibilities for every character space.

Displaying comments 41 - 43 of 43 in total

Sign In for Full Access
» Forgot Password? » Create an ACM Web Account
ACM Resources