What is a reasonable and secure password requirement for user registration?

Question

This is the password policy I just got from UPS (just for package status checking):

Your password must be between 8 and 26 characters long. It must contain at least three of the following character types: lowercase letters, capital letters, numerals, special characters, or spaces. The password may not contain your User ID, your name, or your e-mail address. (SSO_1007)

I actually have to wrack my brain somewhat to generate this password, but not only that, most importantly, I am sure that after 3 days I will forget what this password is. Users won't be so happy. Password reset can be frequent. I think users will try to avoid using the site unless they have to.

What is a reasonable and secure password policy when setting up a website? I think some companies may fear some hackers trying passwords a million times or more, so they add all those requirements for "special characters, lower case, upper case", but won't it be reasonable to turn off the account or just disable the password and require a password reset if a user has tried 30 times or 100 times? Or, add a 5 second delay each time after the user tried 30 times? If so, then those special characters won't be that much needed.

Answer 1

To be honest, I find having strict password requirements to be an annoyance and not a benefit. I would say as a rule the most reasonable is to just specify a length, maybe special characters + alphanumeric. Anything more is asking for people to write down their password, which defeats the whole purpose of having secure passwords. I also hate having to change your password every x days with the usual ridiculous set of rules (e.g. cannot re-use the last 25 passwords) - again all that does is force people to write the thing down so they don't forget, at which point you might as well not ask for a password at all.

Answer 2

My opinion is that passwords should have only a length requirement. You don't want someone putting in "a" as their password. And as the xkcd answer shows, an extremely difficult to remember password isn't always that secure. Always allow people to change their password as well. And forget about the "you can't use any of the characters contained in your previous password" crap.

Making an obscene password policy will do more harm than good. At the college I went to the password policy was similar to the UPS policy AND you had to change it every 2 weeks AND you couldn't use the previous 50 passwords you used. So, what my teachers recommended when setting us up accounts is to use our regular password that conforms to the rules and add a counter to the end of it and put in your password hint what the counter number is.

Also, a strict password policy won't do anything whenever your plain text database gets hacked by a SQL injection bug... or you email passwords to your users and it gets intercepted..

Basically, don't make your password system a hassle for your users or it will encourage them to do insecure things so that they can work around it. For instance, my company when getting a dedicated server from a data center, they set us up passwords that were 20 characters long. They were too secure to be emailed to us and had to be faxed. We couldn't change the passwords, only request for a new 20 character password to be generated. And it was this way for every user... so what we ended up doing is just making a text document on our desktops with the password. Also, we don't use them anymore because for all the "security" they had, they were really quite insecure.

Answer 3

Be sure to allow spaces. Everyone I know can type short phrases faster than they can type the first letter of each word in the phrase. Eg try typing Bird in a Tree and then BiaT. This has the advantage that if you write a vaguely work appropriate phrase like pick Up milk or Meetings all day on a sticky note, it isn't obviously a password.

I'm not a big fan of the "you must have numbers and symbols" rules, but if you apply them consistently (eg i is always 1, a is always @) then you can still write the English phrase on the sticky, apply the known-only-to-you-leet-speak rules, and enter B1rd in @ tree on the password dialog. From a security point of view, the numbers and symbols don't add much, but they don't need to make you crazy as a user.

Sites with maximum password length make me angy if my nice phrase is deemed "too long". 26 seems reasonable. I understand someone has to design the width of the column, but 12 is just stupidly short.

Answer 4

Secure vs. Convenient

The security policy of a password should be appropriate for the cost of compromise. If your website fronts my financial account I would like stringent password protection. If it is a niche fan site about Autobots, you don't need very much protection.

The UPS rules are reasonable with the exception of:

• The maximum length is way too small. You should facilitate the use of passphrases which are easier to remember and can be more secure.

I didn't see the reset after X number of tries in the quoted rules, I think this is silly in most cases. I think your better off locking someone out for a period of time, rather than forcing a reset. This implies a certain level of security. If that isn't necessary, then it's not and locking/resetting is a moot point.

There are many password policy rules that having marginal security benefits at best. However, there are also rules that do have real, tangible benefits to the security of your password.

Rules (and the reasons):

• minimum length

Prevents a combinatorial trial and error attack which will quickly break very short password.

• proscription against using a single English word (or any other language)

This prevents dictionary attacks.

• forced inclusion of different categories (ie. mixed case, numbers, punctuation)

This increases average attack space.

All these reasons can be traced to minimizing the user's bias in choosing passwords. Most users are biased towards creating shorter, easy to remember passwords. Unfortunately that usually makes the password easier to attack. What most users need are instructions on how to create secure memorable passwords or a longer passphrase.

Secure Memorable Passwords

When I need to create a password with a length limit I always start with a phrase so I have a built in mnemonic. I take the phrase and I get the same positional character from each word. I now have a sequence of just characters. I then choose capitalization, some based on proper names in the phrase, or by pattern (first and last, every other letter, etc). I then add in punctuation and numbers based on some arbitrary rule or pattern. (ie. all 'j's are 7, using '&' where there is an 'and' in the phrase, etc).

Mama, just killed a man. Put a gun against his head. Pulled my trigger, now he's dead.

Phrase provided by Queen

1. mjkampagahhpmtnhd - first letter of every word
2. MjkamPagahhPmtnhd - casing matches casing of phrase
3. Mjk0mP0g0hhPmtnhd - changed 'a' to 0
4. Mjk0mP0g0()Pmtnhd - changed 'his head' to ()

After I type it a few times when thinking the phrase I'll never have a problem remembering.

Answer 5

Your password must be between 8 and 26 characters long

The minimum password being 8 characters long is a legacy of Lan Manager. Lan Manager hashed passwords by breaking them up into 2 7-character strings, then hashed them. By requiring 8 chars minimum, they guaranteed that the 2nd word was not the same as for a blank password (there was no salt, so every instance of 7 blanks hashed to the same result).

I am sure that after 3 days I will forget what this password is.

I've given up, the rules are so silly and rediculous that I write them down now. All except the few I use for websites. My current employer also keeps track of the past 24 passwords used so that they cannot be recycled, nor can the password contain any 3+ character English word (forwards or backwards). It also makes sure you don't use a previous word and increment some number as part of it (so if P4ssw0rd1 were used, you could not use P4ssw0rd2, nor P4ssw0rd0).

I learned my lesson the hard way at the office when I had to change a password, it took 45 minutes to get the system to accept a replacement, then promptly forgot what I had come up with and had to get it reset and wasted another 45 minutes trying to get something I could remember that was complex enough to meet the requirements (some of the requirements are listed above, some aren't, and some I don't know). It is not a lot of fun trying to come up with something that meets rules you aren't allowed to know. At least with games like Mastermind you are given clues as to how close you get. At the office, some folks get to use a smart card, I'm not one of them.

Answer 6

Using bcrypt when storing the password is a good first start, simply because it makes brute-force hacking attempts unfeasible.

Answer 7

Reasonable and Secure are mutually exclusive. They are two ends of a rod. Striking a balance in the middle will be best. To far towards secure and people write down the passwords or use the totally un-secure password unlock feature.

The above example does appear to be leaning more towards secure than reasonable. I have seen worse.

I prefer leaning towards the reasonable. The key is to lean towards the secure in your back-end. Store as little as possible use salts etc. All the latest recommended methods for encoding the passwords into your database and encoding them one way as well. Then keep your database and your code secure. Also train anyone that has admin rights to your system that they need to use a unique secure password. It was shown recently that stringing together multiple dictionary words is more secure than dragging in special characters and case. It required compound dictionary matches which really add up time wise for hackers, however, these were still memorable for users.

Answer 8

Not a dictionary word, or a trivial variation of it. That's it. A bundle of two dictionary words is pretty much uncrackable. A single-letter substitute for a character that is not an obvious substitute (0-O, 1-I, 5-S) too.

Also, if you limit response time - password accepted/denied after 1s, and no two parallel attempts for the same login allowed - one must finish (OK or error) before you try another, any non-dictionary 6-letter all-lowercase no-special-characters password will take 9 years to break.

Answer 9

The complexity of password requirement should be balanced with the contents of your sites. A bank should require a highly complex password (uppercase, lowercase, number, and special characters). However, if the content is trivial, like saved searches and tracking numbers, the password requirement should be relaxed. Minimum length of 6 characters should be sufficient. Otherwise, it will simply annoy your audience and deter them from creating a login.