Tuesday, May 13, 2014

The Best (First Good) Password Policy Ever!

In the past I've discussed a number of aspects of the password dilemma.  Among the key issues are
  • good passwords are hard to remember, and;
  • passwords you can remember are easy for attackers to guess.
   But, maybe one of the key issues is that password policies are universally so bad that consumers can't do the right thing because they can't figure out what that is!  We've been living with that old dogma of.... say it with me...
  • 8 characters;
  • upper/lower case;
  • numbers;
  • special characters.
   That's been around since the 60's.  Perhaps it worked in a world when people had only one password, when systems weren't all networked together, and attacking systems wasn't the lucrative business it is now.

   I have finally seen a password construction policy that makes sense.  It came out from Stanford University a couple of weeks ago.  There were some reports on this, but I didn't see as much coverage as this deserved.

   This is the most intelligent password policy I've seen.  Basically, it leverages a key fact of password construction... size matters!  So, the longer the password, the few character types are required.  Here is a summary:
  • passwords must be at least 8 characters long;
  • 8-11 characters require: upper/lower, numeric and special characters;
  • 12-15 characters require: upper/lower and numeric;
  • 16-19 characters require: upper and lower characters;
  • 20+ characters... whatever you want!
   They also provide a great example of using 4 separate words as your "password".  This infographic explains it nicely:

   What's not clear to me is if these passwords expire.  I'm not a fan of forcing expiration of passwords simply based on the calendar.  Passwords should be changed when there is a reason to change them.  The only issue there is that if a password does get compromised, and it's not apparent or you don't realize it, you could be out of luck.  Damage is limited when you don't reuse passwords.

   Of course, I'm still mostly a fan of using password vaults with totally random passwords generated by the vault.  I've written about vaults a number of times.  My favorite is still LastPass, but KeePass is also highly rated and 1Password and PasswordSafe are also good choices.

   What are your thoughts?  Do you think a "sliding scale" password policy like Stanford's would play well at your organization?


  1. Barry - great post - as usual! One comment on the expiring password concern, I recently saw a similar statement from Lance @ SANS...many organizations have had their Id's & passwords compromised (FaceBook, LinkedIn, Twitter). Studies show over 80% of the public utilize the same password across multiple sites. Forcing a periodic change of the password can provide some benefit when an Id & pw is stolen and attempts are made to use the Id & pw on other common sites. It's not the strongest control and with all controls, there is a need to balance the risk/reward, and this is just one more arrow in the Defense in depth quiver.

  2. Hi Randy, good comments. Password reuse is definitely a problem. In this post, http://securityandcoffee.blogspot.com/2013/10/online-self-defense-passwords.html, I talk about a study stating that the average person has passwords on 25 different sites, yet they use on 6.5 different passwords! A great attack case here is to try stolen credentials on bank sites, retail sites, etc. I think the only solution is using unique passwords - and use of a vault really helps support this. Back at the office we should remind staff to not reuse work passwords at outside sites.

  3. This implies, of course. that the implementation can support arbitrary lengths (20+). In practice, this usually means that one way hashes are used. This is because no matter the length of the input, the output of most hash algorithms produces a fixed length as output. In other words, Stanford University is not likely storing a blob in their user store.

    This also implies that other items in the policy do not contradict a hash method of storage. For example, if the system cannot reverse the hash (without resorting to brute-forcing itself), then you can't make a rule that says that a new password cannot be the same as any of the last 12 (you can only assure that it's not the same as the one being replaced). Of course, if you don't favor expiring passwords then this is not likely going to be part of your policy.

    Great food for thought. Thank you.


  4. Of course, you could save your last 12 hashes. So to be more specific, the policy can't say "too similar" to previous 12. In THAT case, your policy is effectively demanding storage of cleartext passwords (and probably contradicts another clause that says you can't use cleartext storage).

  5. From the system side, I don't see my (government) organization ever accepting this sort of flexible approach, we are married to those 8 characters. Plus, I finally manage to construct I can remember and then it expires. As if every month some hacker is working away trying to guess mine and just before he gets the key I change the lock? Don't think so. As a consumer I LOVE this. I can create longer passwords that I can remember, potentially varying something I can remember about each site so I can have a slew of strong passwords I can remember without repeating the same one all over the internet. ( I do use a vault, , but this could save some steps and help when I am on different machines.) Thanks for the post.

    1. Jarrod - You are correct that 1-way hashes are definitely a requirement. I definitely favor either non-expiring passwords or longer expiration intervals. I don't believe in changing a password base solely on the calendar.

      Diane - you must help lead the charge! There are other universities that use this policy. Granted, they are not like full-out gov't agencies, but many are part of state government. I think part of the problem is that we need good tools that can handle these non-standard policies. Your other point is on expiration - and, of course, we did have non-expiring passwords for a while but fed audit requirements forced that change. We'll continue to push for modern policies across the board. And, of course, if we all can use vaults then may we don't care how complex a pw is nor how often we may need to change.