Punishing users for insecure passwords

Question

I'm thinking about limiting the rights of users who choose insecure passwords (insecurity of a password being determined by length, how many types of characters (upper/lower case, numbers, symbols, etc.) are used, and whether it can be located in a rainbow table) to limit how much damage their account can do if compromised.

I don't have an application for this idea yet, but say I'm writing a forum or something: Users who use 1234 as a password might have to fill out a captcha before posting, or be subject to rigorous anti-spam measures such as timeouts or Bayesian filters rejecting their content. If this forum is very hierarchical, allowing for "promotion" to moderators or whatever by some means, this would either stop them from gaining privileges at all or telling them they have privileges, but not letting them exercise them without a change to a more secure password.

Of course this couldn't be the only measure of security, but it might go well next to otherwise good security practices.

What do you think? Is this just overdoing it, stealing focus away from more important security practices, or is it a good way to limit risk and encourage users to use safer passwords (and hopefully convince people you are using good security practices)?

Answer 1

YAGNI, KISS, DRY, the 10 second rule and the fact that "[u]sers don't care about YOU" should probably narrow it down to one solution: Don't.

• It's more development work which would need a lot of testing to be reliable and secure.
• It probably reduces the security of the site any way you look at it. The chance of some bug leading to privilege escalation with a terrible password is just too big.
• It increases complexity for the developer, tester, maintainer, DBA, sysadmin and user.
• The more complexity, the harder it is to avoid repeating yourself in some way.
• Users don't have the attention span to read your information and follow up on it. They are used to tweaking the registration form until it accepts the input, not until they reach some ideal level.
• Users just don't care.

Answer 2

Either force a secure password at registration change, or use an OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html). Then concentrate on more interesting functionality.

For one thing, users are used to being forced to create secure passwords or using their OpenId, so it's simple for them.

Answer 3

Why allow passwords you feel are bad in the first place? Stopping the problem at the source is going to save you lots of design time trying to figure out what classes of passwords map to what roles. Since an admin, by definition, would have full rights, you would already need functionality to ensure he does not enter a password that would restrict him.

My answer just really comes down to KISS.

Answer 4

As a user, that would probably convince me not to use your site. I mean, seriously, my bank tells me a 6-digit code is perfectly safe for online banking, but when I want to write a comment to some lesser-known blog, I'm supposed to remember a unique password containing at least 8 upper- and lower case characters, a digit, a special character and a Greek or Cyrillic symbol that can only be entered if you know the unicode sequence by heart. And change it regularly.

Don't get me wrong, security is important. But if you shouldn't annoy your users unless you have really strong reason to believe that someone will try to crack their passwords to gain access to your site. If your site happens to provide VPN access to the FBI network, go ahead, annoy. But if it's a user forum where anybody with an email address can sign up, what's the point, really?

Answer 5

Better solution: smiley faces.

I'm serious! Reading behavioral economics books like "Nudge: Improving Decisions About Health, Wealth, and Happiness" had convinced me of a few things:

1. You cannot get force everyone to make wise decisions.
2. People like to be free to choose, but they don't like a lot of options.
3. You can, however, significantly influence their choices for the better with simple tricks.

I see these principles apply to your situation like this:

1. Restricting users based on insecure passwords is most likely going to frustrate and confuse them... especially for the majority of people who do not read the carefully-written explanations in dialog boxes, and just call the Helpdesk to say, "It doesn't work."
2. When creating passwords, users don't need to see a list of all the possibilities of special characters and such they can use. Better to show them a little pop-up suggesting they add some complexity only if their entry doesn't meet the requirements.
3. People are strongly influenced by social cues--even little ones like happy faces showing that we approve their behavior, or frowny faces if we don't. Some of the better-designed websites will show a colored progress bar that changes from red for Not good enough :( to green for Good job! :) as the user types in their (proposed) password and confirmation. This UI gives them some social pressure to meet the standards--to get the bar to turn green, or change the frown into a smile--as they discover for themselves how to create more secure passwords with the aid of the immediate feedback of the color changes.

Answer 6

Not to pile-on, but I thought of another reason to file this under "Bad Idea" I haven't seen mentioned yet -- customer support.

If this is a product that's going to have customer support reps behind it, they're not going to like this very much. One of support's underlying assumptions is that they understand and can predict the user experience -- if they're assisting a regular user, then Page 1 should have links to Pages 2, 3, and 4, where they can do X, Y, Z, etc.

Now, you're giving them another variable they have to keep track of. If the user doesn't see the link to Page 4, is it because they did something stupid? Or is it because their password sucks and your system is punishing them by denying them access to Page 4? Wait ... crap, is denying access to Page 4 one of the punishments for a bad password, or am I thinking of Page 5? Let me look that up, just one moment ... okay, it says that for a password that doesn't mix upper and lower case letters, access to even-numbered pages is allowed but restricted to read-only ... okay, sir, your password, does it consist of all upper case or all lower case letters? Case. When you just type the letter, that's lower case; when you use shift, that's when it's upper case. Did you mix the cases in your password? The password you used to log into the system. The one you just used. Okay, go to Edit, then select Preferences, then Security. Select "Saved Passwords" ... no, sir, I can't see your passwords from here....

Yeah. Don't do this.

Answer 7

Either restrict passwords or inform users of the risks of weak passwords. I guess if a user doesn't care about their data you may want to restrict access to other's. Maybe users feel more confident if those who follow careless password practices are weeded out. What's the point of requiring a stronger password if it is going to end up on a sticky note under the keyboard or taped to the laptop (Can't make that stuff up; I've seen it happen.).

Answer 8

and whether it can be located in a rainbow table

I guess you mean dictionary and not rainbow table. The dictionary attack works on just testing all words of the dictionary if they match the password. This attack can be fixed by 5 attempts and blocking for x minutes...

A rainbow table will only be used if you hash the password and the attacker knows the hash. Than he might be able to find the hash in the rainbow table if it was just "12345" or something similar.

Just to complete the round trip: To make a rainbow table useless you should salt the passwords. And use a unqiue salt for every password and not just one for all. If you do that, the attacker need to create a rainbow table with the unique salt for each account he want to access. Clever done by your side, you can spice up the hashing with concatenation multiple hash algorithm so that one generation might take a half second. If you have done this, accessing an account on your website must be worth days, probably month of generating hashes to find a match to this account... I can't think of a attacker that will try to get all passwords when it will take that long.

For the time of hashing: Think about 500ms waiting time for a login mechanism. I think it is acceptable... (a reminder: nearly one second takes a hand shake for SSL)