views:

1166

answers:

10

This is something that's been bugging me for many years: why most online services highly value the entropy of a password, citing it as a security measure, and enforcing it when users select a password?

I decided to come out with this question after reading the paper "Do Strong Web Passwords Accomplish Anything?" (and, of course, classic Dilbert cartoon).

The typical policy of an online site is to require at least 6 or 8-digit upper+lowercase+numeric password. This length is somewhat relevant for the difficulty of brute-force attack to e.g. recover a password from hash. But the typical way guessing happens online is that somebody tries to log in into the server, which is free to refuse after a couple of attempts.

Let's imagine, for example, that we are protecting some medium-sized service with an all-digit PIN. One immediately thinks about 4-digit or 6-digit pins, but that might be not a good idea as too many people will be tempted to enter their children's birthdays, which are essentially a public knowledge.

So, here's my 5-digit PIN suggestion. I keep for each user a "possible attack" flag.

  1. User logs in correctly -> OK
  2. Otherwise, keep the https session and allow 2 more tries
  3. User logs in -> OK
  4. Otherwise, allow 2 more tries with a 5-minute break before them
  5. User logs in -> OK
  6. User breaks session -> set the flag
  7. User breaks session but logs in normally later: present user with the dialog and allow to clear the flag
  8. User exhausts the tries above: send email with the link; allow to clear the flag
  9. If there are more than 100 flags overall during the month, set the global "possible attack" flag which requires that people who don't have a cookie answer security questions
  10. Automatically clear the user flag in some cases (e.g. user finally logged in from the same computer)

Let's assume that the user names are somehow known (note this won't be true for most sites). A brute-force attack against one user is hopeless -- you're locked out after 5 attempts, so you have a 1/200000 chance. If you try to guess password more than 200 times in a month, the flag goes off and you get nothing. If you try <200 users per month, after a year you have < 1% chance of breaking one user; you're much better off with phishing, viruses, social engineering or anything else.

The size of the site is relevant only in the sense of not getting false positives, that is users who genuinely forget their password (let's say 1% per month), recover it, but don't clear the flag (let's say 1% of those), and when you can't clear the flag automatically (say, 10% of those). This makes for 10 expected false positive flags per month per 106 users --- which means that a medium-sized site has a reasonably low probability of entering "panic" mode, which anyway isn't that bad.

I believe that this scheme is very practical. Here are some obvious first facts about it (updates):

  • benefit: The PIN is easier to remember. I believe this is a big benefit since it's now possible to require that user remembers the password you generated. I believe most people are much better remembering 5 random digits than any other type of random password.
  • tradeoff: Hashing will not help much if your attacker knows both the hashed PIN and the salt. This is possible if somebody broke into your database and learns what's your salting process. However, I believe the standard password entropy doesn't help in that case either.
  • benefit: people are much happier remembering random 5 digits than random alphanumeric passwords; therefore it's much easier to also require that we generate the password, not the user. This eliminates dictionary/personal data attacks.

My questions are:

  1. What are the other tradeoffs/benefits of my scheme compared to the one I described as typical?
  2. Won't be most medium-sized sites and organizations better with my password scheme?
  3. What are the reasons they select the scheme they have?

Note: I don't advocate always having short passwords. My own web passwords are usually randomly generated and encrypted by a password manager (1Password) with 12-character high entropy password. But I think that often the scheme above would be better than what we have in practice.

+33  A: 

No, you're mistaken. Brute force attacks are one thing, but the real danger is Rainbow Tables that, from a hash value, gives you the plaintext password.

First you never ever store anything as plaintext. If someone breach your security (or even if an employee has malicious intent) you don't want to expose users' password. So you will use a properly salted hash.

Then, with a 5-digit PIN, it's way too short to protect with hash. There are rainbow tables (or even Google searches) that would allow someone to get the password back if they get the hash.

Ksempac
+1, and I'd give you +10 if I could. A great answer. Never ever put anything in plain text, always be wary of your own people, and never assume that your database is secure.
Eric
Well, this is there under 'tradeoffs'. But could you please elaborate about what is the difference with typical passwords - I believe more than 50% are root + uncommon postfix. How is that that much different? You have to regenerate all passwords after the break and restore the backup, anyway.
ilya n.
You want to protect your customer's account even in the case of a database break. If you put password in plaintext, you're already screwed. If you put hash, you have to have strong hashes because of "rainbow tables", tables of pre-computed hashes for all the possible values in a given set of characters. But this work only for small set of characters because you need quite a bit of computing power to calculate all the values. A lowercase+uppercase 7 letters password makes for 52^7 values that's more than 10^12. With only numbers, even with 10 numbers, you get only 10^11 values.
Ksempac
Replying to my own comment because 600 characters is too short.There are rainbow tables available on the net for small set of characters. The more characters you add to your password rules, the less likely someone will have created a rainbow table against it.About the "restore" thing. Sure, after the break-in, you need to restore everything, and set up new security. But what matters is that the one who took your data can't do anything about it. He must get only useless hashes. Otherwise, he will get your users' account before you even notice he stole your passwords database.
Ksempac
@Ksempac: I think you don't get 52^7 since most passwords have predictable structure (uncommon root + common suffix). You get much less, so practically you're screwed in somebody steals the database anyway.
ilya n.
Sure it's hard to protect someone who took "password1" as his password (note that salting your hashing will still gives some protection). But what is important is that users who do pick good passwords will be protected. If you restrict me to a 5-numbers password, any password i pick will be in the attacker's rainbow table. Actually, even when I'm a browsing for fun, i tends to avoid websites with too many limits on password choice.
Ksempac
Your "predictable structure" argument doesn't work. It is *trivial* to enforce a secure password policy, preventing common suffixes, a decent minimum length, requiring mixed case, numerics, symbols.
Peter Boughton
@Peter, this is very reasonable. But 90% of people never remember passwords like that.
ilya n.
Peter Boughton
For some actual stats about real-world passwords, this analysis of the passwords obtained via a MySpace phishing attack is interesting reading: http://www.schneier.com/blog/archives/2006/12/realworld_passw.html
Brian
@Brian: yes, that's what I trying to cite.
ilya n.
+1  A: 

Passwords with salted hashes are best. The Salt prevents most rainbow attacks and a password is much more difficult to brute force. Even with a dictionary attack you would be more likly to get faster hits on a 5 digit pin then on a similar length password.

Matthew Whited
As an alternative to a commonly used global salt I use the users-ID from each account to prevent mass attacks that are still possible by only using one.
merkuro
You can salt with User ID a pin with the same ease as password. They are not different in this respect.
ilya n.
Because your PIN would only use 10 characters (0-9). A password would use at least 36 (0-9 + A-Z). Using punctuations and case sensitivity this goes well over 60 characters. If you allow all ASCII characters you now have 255 (0/null would be problematic). With these possible combinations of character you can see why a password would be much stronger than a PIN. I do agree that forcing users to change passwords often does make them more likely to write them down (because they would otherwise forget it.) I can almost allow changing a password once a year.
Matthew Whited
Also random salts at much better than using a global or username. But any salt will prevent most rainbow attacks.
Matthew Whited
Actually appending the userid to the salt ensure two randomly generated salts are never identical (astronomical odds I know).
jmucchiello
random salt + password matching between two people? I guess you could use the username, but what if you rename the user account?
Matthew Whited
+1  A: 

I have suggested a scheme similar to yours in the past because I have seen plenty of cases where users simply write out the passwords on a sticky note next the their monitor citing the complicity is too difficult to remember. I argued that passwords don't matter too much because a hacker is more likely to find other holes in the system, be them via the application or simply by a little social engineering.

I think some people, especially technical managers who don't fully grasp what you are saying like a the sense of security. A big complicated password feels strong. Kind of like a guarantee on a box, it makes you feel good. Kind of like the tooth fairy

"Tommy: How do you know the tooth fairy isn't some crazy glue-sniffer. 'Buildin' model air planes,' he tells them. Well I'm not buying it. He sneaks into your house once, thats all it takes. Next thing you know you got money missing off your dresser drawer and your daughter's knocked up."

Ultimately though a simple password like a pin is likely to be cracked or guessed with common combinations, and it doesn't feel safe. A pin in combination with an RSA SecurId is what we were all able to agree upon.

Bob
+12  A: 

Keep in mind that a malicious user with 3.000 attempts can successfully block 1.000 accounts within minutes. Another thing is that he can change the odds of one successful login by trying thousands of different accounts a day. Is OpenID not an option?

Update

Just had a little inspiration about the 5 digit thing. If 5 digits (10^5=100.000) are really easy to remember and safe at the same time what about these cases:

4 letters all lowercase (26^4 = 456.976) => abcd
3 letters with mixed cases (52^3 = 140.608) => aBc
3 letters lowercase + numbers (36^3 = 46.656) => ab1
merkuro
+1 for suggesting bypassing the issue entirely with OpenID.
rmeador
Not really "block". Those who are logging in from the same computer as before will sidestep the block. If you read the algorithm, when there are many login attempts the whole thing starts requiring security question from anyone after 100 account attempts.
ilya n.
Sorry I probably have misread your proposal. However an attacker might not be only coming from only one IP-Address (tor, proxy, redial, xss attack/javascript from other sites). Another thing is with current dialup connections everywhere, I probably wouldn't limit a user account to a specific IP, because it could change after 24h. I personally prefer to create a very long random key for important sites and this PIN-Code could potentionally limit me in my approach.
merkuro
@merkuro - I'm talking about minimum length and minimum requirements... You can do anything you like, but most people will go for the easiest password :) Also, I'm not advocating locking user to his computer+browser, just that in some cases ask them to answer security questions if they don't have the cookie.
ilya n.
+2  A: 

Beware of session-handling

I don't know too much about session handling, but as much I know, it is most of the time made using cookies. When you have a scheme like yours, it is necessary to write false attempts into the database or into special files on your server, since you can't rely on the session handling (in your description it sounds a little, as you just can "hold the session" to have all the truth...) -- since sessions over the internet are very vulnerable. It is just a construct of cookies (which can be deleted) and/or page names (those also can be tainted). The only thing you can rely on, is that the user still holds the session -- you can't really identify wheter some (seamingly) new connection is not your old user ...

Specially, it makes no sence to differenciate between "User has still session" and "User breaks session" (your item 7) this is just a neglectible difference and can also become a security hole.

Remembering is not really easier

You also say, that remembering 5 digits are more easier. That might be right for your credit-card or bank-card (in Germany, we have 4 digit PINs) security number, but for websites, you always have the problem, that those many websites have passwords. To remember dozens of 5 digit numbers is as difficult as plenty of passwords.

Juergen
A: 

PINs vs Passwords, passwords win, not perfect, but with strong policy, far better than PINs.

And who said many people don't write their PINs on sticky notes, Its easier for many to remember a word combination than a 5-digit number, personally, I remember numbers easiest, and thus my passwords are more numeric than alphabetic.

BakerTheHacker
+1  A: 

I think it'd be easier to remember "passphrases beat PINs any day!", which will hold up to a brute force attack for something like 400 trillion years.

Daniel Straight
I'm specifically not talking about brute-force attacks.
ilya n.
It's still easier to remember. If the server is going to implement a strong policy of lock outs, you may as well just use dictionary words. Even a four letter word will be impractical to guess if the server locks out enough. So, if brute force protection is important, use a passphrase. If it's not, just use words. Why introduce a PIN? Is 21241 easier to remember than "pasta"?
Daniel Straight
@Daniel: +1 for your comment. For me, I guess, 21241 is easier :)
ilya n.
ilya: That is not typical.
jmucchiello
+2  A: 

I still don't understand why people limit password lengths at all. Wouldn't it be easier for me to remember a sentence or phrase? For example, I might want my password to be "this is my stackoverflow password". I would have some serious memory issues if I forgot that. It's length is 34 characters and only uses an alphabet of 27 characters, but still would be essentially impossible to reverse the hash (4.6 x 1048 possible permutations).

Combined with your ideas regarding the "attack flag" and proper salting/hashing techniques, this would be an ideal solution in my opinion.

John Rasch
I was hoping someone had raised this - pass phrases are massively underused. It's a pity websites tend not to support/encourage them.
Peter Boughton
I certainly agree that having a passphrase or a long password stored in a secure password manager is the best, that's how I do things. Yet we're talking about design for average user.
ilya n.
Variations of this is my stackoverflow password are, by the way, like 5 bits or something :)
ilya n.
But then you have the problem of a dictionary attack that single-word passwords suffer from. I would hazard a guess that a pass phrase is not any more secure than a randomly-generated string of 8 characters.
DisgruntledGoat
Well assuming (just English) has 500,000+ words in the dictionary, it would be tough to generate this randomly. You could always throw a number or symbol here or there to prevent that as well.
John Rasch
+1  A: 

The real problem? People.

I know a school district with 4 passwords: 1111, 2222, 3333, and 4444. Why? The users got together and agreed to do this so they could always get in when staff was home sick. Too much of a pain to get into a locked lunch money computer when the lunch worker was sick.

Oh yeah, I saw the lunch computer unattended many times. And, yes, you can ask to have your balance turned into cash at any time.

Users are insane.

Nosredna
+1  A: 

By that logic, if 5 digits are easier to remember than 8 characters, yet contain sufficient entropy, then one digit and three case-insensitive letters should be easier still!

10**5 = 100,000
26**3 * 10 = 175,760

Now just four little characters, yet they convey more entropy!

Perhaps I'll just use my initials followed by the digit 1 . . .

I'm not what's proved by this except that there's a big ambiguous gray area between reductio ad absurdum and sarcasm.

Marsh Ray