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)?

  • 24
    What is the benefit of this when you can already restrict users with improper passwords from even accessing your system at all? – Pete Jul 12 '11 at 12:15
  • 12
    Most people will probably keep using "letmein" regardless of whatever restrictions you place on them. Either enforce the password rules when creating/changing a password or don't. – John Straka Jul 12 '11 at 12:17
  • 3
    @Carson Myers: Not if you fashion it out of Cat6 cable it isn't :D – Piskvor left the building Jul 12 '11 at 12:38
  • 13
    First, users of what? I'm tired of websites that require login to see an image posted on a forum, then require the password to be mixed-case 10-character with digits and special characters and WITHOUT underlines and the number 1. Make the password requirements proportional to value of data protected. – SF. Jul 12 '11 at 12:58
  • 6
    In Florida, people who were late paying their cable TV bills sometimes got limited to one channel. CSPAN. It worked for them. <shrug> – Mike Sherrill 'Cat Recall' Jul 12 '11 at 13:29

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.
  • strong points, all, except maybe DRY. Why DRY? Also, it doesn't have to be that complicated, the whole "promotion to MOD" etc was just a few extra examples. Since most websites already detect insecure passwords, and many common platforms (Wordpress comes to mind) already allow you to register with insecure passwords, does adding captchas for these users raise all of these concerns? It might be annoying, but the other alternatives are turn users away completely, or let them in and risk more spam. For example. – Carson Myers Jul 12 '11 at 13:01
  • 3
    +1 For the link to useit. Good site is good. Ironically ugly for a UI/UX site. – StuperUser Jul 12 '11 at 13:09
  • 4
    +1 For Users don't care about you. If it is some silly blog/Q&A site and I have to remember a complex username/pwd combo I simply won't use it. – ElGringoGrande Jul 12 '11 at 13:25
  • @ElGringoGrande I'm not necessarily proposing it for something silly, rather as a middle ground between "allow all passwords" and "reject all bad passwords," where there are plenty of sites employing each method. It's not faring well however, haha – Carson Myers Jul 12 '11 at 13:31

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.

  • I agree that OpenId is great for this sort of thing, but I think you may be biased in thinking that most users are used to either of those things. Most people I know have never heard of OpenId, and even more use insecure passwords – Carson Myers Jul 12 '11 at 12:27
  • 1
    Good point. I didn't use OpenId before SE, but I had had passwords rejected due to a lack of complexity. If it's between keeping something simple and secure, then security comes first, even if the responsibility for educating your users is down to you. You'd have to spend effort educating them as to their responsibilities based on their password complexity, it seems better to use it to educate them in security/promoting a common login. – StuperUser Jul 12 '11 at 12:34
  • a common login is ideal, but if the application isn't technical in nature a good portion of users will choose to just use their same password (or leave if that isn't available). In my example, I'm wondering whether it should come down to turning users away (by rejecting their password), or giving them a visual experience (we can't let you do that because we don't know if your bad password has gotten your account compromised) to show them the problems created by bad passwords – Carson Myers Jul 12 '11 at 12:45
  • Most users will have a facebook or hotmail or Gmail account (a mail account is needed for credential retrieval on many sites), making it clear how to use those for sign up/login may be useful. – StuperUser Jul 12 '11 at 12:48
  • I guess I forgot about facebook connect etc. – Carson Myers Jul 12 '11 at 12:51

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.

  • 1
    This is not a solution, because this tends to push user to adopt countermeasures which broke up even more you security policy. – deadalnix Jul 12 '11 at 12:23
  • @deadalnix how so? I think he's just saying to forgo the whole idea and just reject bad passwords, while providing an example of why my idea might cause more irritation than is necessary – Carson Myers Jul 12 '11 at 12:26
  • @deadalnix what do you mean? What countermeasures against a secure password would a user adopt? – StuperUser Jul 12 '11 at 12:26
  • 7
    @StuperUser: This, most notably: switching one vulnerability for another. – Piskvor left the building Jul 12 '11 at 12:37
  • 1
    @StupidUser: If a user is reusing the same password for every site, and they get told "mypassword" is not acceptable because it doesn't contain any numbers, there is a pretty good chance they will just put in "mypassword1" – elwyn Jul 13 '11 at 8:13

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?

  • Well for one, if we're talking about a community site, spam can be an issue (and really has been in some project I've participated in). IMO it'd drive away more users to just outright reject their password, and if we're going to be mitigating spam by using captchas (not uncommon) better to put that annoyance on the users likely to cause it, no? – Carson Myers Jul 12 '11 at 13:21
  • Also, I think it's a common misconception that it's rare to get attempted breakins if you're small. I've been involved in a couple of small to medium online communities, and it was always a problem. This ServerFault question seems to support that. – Carson Myers Jul 12 '11 at 13:22
  • 5
    why would spammers use shorter passwords? Why would they try to crack other people's passwords, if they can just create a new account? I don't see the advantage of long passwords here. – nikie Jul 12 '11 at 13:25
  • I have no idea, I just came up with it a little while ago and decided to see how it stood up to scrutiny :) not well, it seems... – Carson Myers Jul 12 '11 at 13:28
  • 1
    I so like your answer because it points out the silliness of even thinking of implementing this idea: creating needless security for site containing non-secure data. – Tundey Jul 12 '11 at 17:23

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.
  • 2
    My initial thought was that you were suggesting requiring users to use smiley faces in their passwords. – aslum Jul 12 '11 at 17:12
  • 4
    @aslum: Actually, smiley faces in passwords isn't such a bad idea. Nearly all of them are composed of non-alphanumeric characters, so just tossing a :) at the end of an otherwise weak password would make it significantly stronger simply by increasing search space. – afrazier Jul 12 '11 at 17:36
  • @afrazier: unless this became common practice, and they could be added to the list of characters, right? – serv-inc Mar 18 '19 at 11:27

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.


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.).

  • Part of my question was limiting users' influence on each other when they used poor passwords, so you don't outright send them away, but you make sure not to turn their bad practice into others' suffering. After this long discussion, it seems not worth it. Still, a fun I idea, I think. – Carson Myers Jul 12 '11 at 18:12

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)

  • Yes, I meant a dictionary, thanks. And you're certainly right that other forms of security are necessary – Carson Myers Jul 12 '11 at 18:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.