Worst Password Policy Ever?

Mark Burnett
XATO
Published in
6 min readJun 14, 2011

I have seen many silly and overly complex password policies over the years, but I think that the TSA’s TWIC password policy has to be the worst I have ever seen. Their password policy is as follows:

  1. Minimum password length is eight characters.
  2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.
  3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).
  4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.
  5. Passwords shall not contain any dictionary word.
  6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
  7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
  8. Passwords shall not contain any simple pattern of letters or numbers, such as “qwerty” or “xyz123”.
  9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit “year” string, such as 98xyz123.
  10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.
  11. Passwords shall not be the same as the User ID.
  12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.

Complex password policies are frustrating and confusing to users and can even lead to habits that subvert the security of the system they are trying to protect with the passwords. But this policy just takes it to a whole new level.

All I can really do is address it one point at a time:

1. Minimum password length is eight characters.

My first thought here is that if you are going to have such an extreme password policy, you could at least set the minimum password length to ten or even twelve characters. The password length is crucial to password security and eight characters just isn’t long enough anymore. Besides, having a longer minimum length requirement alone would eliminate the need for most of those other policies.

2. Passwords must contain at least one of each of the following: one alphabetic uppercase, one alphabetic lowercase, one numeric, and one special character.

Usually I complain about password policies that require all four types of character sets, but in the context of all the other rules below, this one doesn’t seem so bad anymore.

3. Passwords shall not contain any two identical consecutive characters (example: 22apples, 14588904).

I see no justification for how this rule makes someone’s password more secure. Consecutive characters certainly do not make a password more guessable or more crackable and this policy seriously makes me wonder if the writer’s of this policy even understand password security at all. In fact, you could even argue that in the case of a brute force attack that two consecutive characters would take longer than other character combinations. For example, if you are trying to crack the password 14588904 via a brute force attack that starts at 00000000 and ends at 99999999, incrementing by one character each time, then when it gets to 14580000 it still has a ways to go before it gets to the actual password. In this particular case, the password 14581234 would be cracked first even thought it doesn’t have consecutive characters. Overall, the average time for any set of passwords would not be affected at all by this policy and it really seems like a policy created just for the sake of having a policy.

4. Passwords may contain no more than two identical consecutive characters in any position from the previous password.

I’m not even completely sure what this means, but I am guessing that if your previous password was 8qTaYbg$aMVVruEg and you wanted to set your new password to &2Ta3xfWNG=Arn9e, it would be rejected as not being secure enough because it has two of the same characters in the same places as the last password. Now I don’t know if any of their admins have ever tried cracking someone’s password, but you definitely don’t start with the previous password (if you even know that) and start matching character by position.

5. Passwords shall not contain any dictionary word.
6. Passwords shall not contain any proper noun or the name of any person, pet, child, or fictional character.
7. Passwords shall not contain any employee serial number, Social Security number, birth date, phone number, or any information that could be readily guessed about the creator of the password.
8. Passwords shall not contain any simple pattern of letters or numbers, such as “qwerty” or “xyz123”.

These policies started with a good intention and took it one step too far. Apparently their logic is that if your password is something that would show up on a password cracker’s wordlist it is bad, therefore if if your password even contains a dictionary word, then it must also be bad. So if I chose a password like $$Superman&#xyz123, which is a very strong password, it would be rejected by the system as not being secure. Again, I’m not really sure these people understand password security.

9. Passwords shall not be any word, noun, or name spelled backwards or appended with a single digit or with a two-digit “year” string, such as 98xyz123.

This one I somewhat agree with. It is still a little extreme but probably fair. Still, this could be eliminated with a minimum 12-character policy.

10. Pass phrases, if used in addition to or instead of passwords, should follow these same guidelines.

Why did this even need to be said on an already cluttered and confusing list? I think that anyone would assume that the requirements of a pass phrase would be the same as those for a password. I’m starting to think that whoever wrote this was actually trying to make this list long hoping it would make them look smart or something.

11. Passwords shall not be the same as the User ID.

This is the only policy that actually needed to be there, and is something most users have come to expect in a policy. However, this is yet another policy that could likely be elmiminated by having a minimum length requirement.

12. Password length will be selected to provide a level of protection commensurate to the value or sensitivity of the resources or data it protects, but not less than eight characters.

Again, something that totally goes without saying and kind of sounds like something taken from a higher-level policy document. The list of policies is already intimidating enough to users that you really don’t need to be stating the obvious. Besides, if you have to say something like this, why not just make all passwords a minimum of 12 characters or more.

My Password Policy

So what would I use as the ultimate password policy? If I was ever in the position to set an organization’s policy, and it required a much higher than normal security, it would be this:

  1. Minimum password length is 15 characters but can contain anything you want including spaces.
  2. Your new password shouldn’t look too much like your last one.
  3. Don’t reuse this same password anywhere else.

Then, I would provide a short list of example passwords to spark their creativity such as this:

I know that many administrators would have a very hard time with my policy and some people will ask what if a user sets their password as a string of 15 a’s? After all, this goes against what most administrators are taught in school. My answer to that is that the password aaaaaaaaaaaaaaa has not appeared on any wordlist I have ever seen, so far is not in any rainbow tables, would be a strange thing for someone to guess, and would take forever to crack via a brute force attack so I say it’s actually a pretty good password.

Discuss this article on Disqus

Connect with me on Twitter or LinkedIn

--

--

Mark Burnett
XATO
Editor for

IT security analyst and author working in application security, passwords, authentication, and identity. Based in South Weber, Utah https://xato.net