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.
- User logs in correctly -> OK
- Otherwise, keep the https session and allow 2 more tries
- User logs in -> OK
- Otherwise, allow 2 more tries with a 5-minute break before them
- User logs in -> OK
- User breaks session -> set the flag
- User breaks session but logs in normally later: present user with the dialog and allow to clear the flag
- User exhausts the tries above: send email with the link; allow to clear the flag
- 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
- 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:
- What are the other tradeoffs/benefits of my scheme compared to the one I described as typical?
- Won't be most medium-sized sites and organizations better with my password scheme?
- 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.