We Don’t Need No Password Strength Checker
Password strength checkers appear from time to time on web registration forms. But in my opinion they are useless. I’ll justify. Jeff Atwood lists the possible ways to obtain one’s password:
- phishing – password strength indicators can’t help with this at all. We can only rely on browsers to warn users in time, and that users will be careful.
- man-in-the-middle – someone sniffs traffic and grabs the password, if it is sent unencrypted. No matter if it is 123 or Fhfsa!dHJGd4. Solution – use https for login and registration
- brute force – if an attacker attempts to login with a list of possible passwords. A strong password would be helpful here if there was not a standard, best solution to this problem – limit the number of successive unsuccessful login attempts. Such a limit makes the password strength obsolete (in case it is different from 123456 and qwerty)
- educated guess – that is, when someone knows personal details around a given user, and tries passwords like a name of a dog, a name of a spouse or children, favourite sports team, etc. He has to know / guess the username as well. The above technique – blocking successive login attempts helps here as well. Password strength can be useful for this point, but it does not require much more than a digit.
- rainbow table attack – if an attacker obtains the database somehow, he can then have all the passwords. If they are stored as plain text – he has them, no matter how strong. If they are stored as simple hashes, as another codinghorror article explains, password strength does not matter as well – precomputed hashes (rainbow tables) find 99% of the passwords. The solution here is simple – use salt. And let that salt be long and different for each user. If the salt is the same for all the passwords, the attacker (if determined enough), can generate a rainbow table with the given salt. It will take some time, but eventually he’ll have all the passwords. The best solution here is bcrypt.
Enough about the security aspect. Now onto usability. Complex registration forms are undesirable – they drive potential users away. Password strength indicators add to this complexity. Many users don’t actually see the point of their password being strong, because they are not web-security experts. And they are expensive usability experts – if your usability is not good enough, they just leave. I myself often leave if the password I try is considered “weak” after around 3 attempts. And a password strength indicator implies that there are at least 5-6 rules to participate in the calculation.
So, the obvious conclusion what not to do is – don’t add password strength indicators to registration forms. They are almost useless in regard to security, and add unnecessary complexity to the registration form. But what to do?
- have two rules at most, javascript-validated for immediate feedback. Length and digit+char are good options. And let the user know these rules as soon as he clicks on the password field. I’m inclined to even skip the digit+char thing, and impose a lower password length limit – say 6 symbols. Coming up with a long password is tedious. (But see the last point). There can be a 3rd rule, that the password can’t be the same as the username, but it will appear rarely. That’s enough to cover educated guesses. That’s it.
- Use TLS for login/registration (at least. Firesheep reminded us that TLS/SSL should be there more often)
- limit the number of successive login attempts (to 3 or 4 for example). Possibly warn users that there were many failed attempts.
- use salted hashes for password, with a different salt for each user
- seriously consider OpenID. If you are one of the 99% websites, that can’t say “I don’t want external login for political reasons”, go for OpenID. Users login with a single click if they are also users of the other 1 percent websites – google, facebook, yahoo, twitter, etc. Of course you can hope for becoming big, and then you can decide to store passwords yourself. But make sure you are storing them right.
Password strength checkers appear from time to time on web registration forms. But in my opinion they are useless. I’ll justify. Jeff Atwood lists the possible ways to obtain one’s password:
- phishing – password strength indicators can’t help with this at all. We can only rely on browsers to warn users in time, and that users will be careful.
- man-in-the-middle – someone sniffs traffic and grabs the password, if it is sent unencrypted. No matter if it is 123 or Fhfsa!dHJGd4. Solution – use https for login and registration
- brute force – if an attacker attempts to login with a list of possible passwords. A strong password would be helpful here if there was not a standard, best solution to this problem – limit the number of successive unsuccessful login attempts. Such a limit makes the password strength obsolete (in case it is different from 123456 and qwerty)
- educated guess – that is, when someone knows personal details around a given user, and tries passwords like a name of a dog, a name of a spouse or children, favourite sports team, etc. He has to know / guess the username as well. The above technique – blocking successive login attempts helps here as well. Password strength can be useful for this point, but it does not require much more than a digit.
- rainbow table attack – if an attacker obtains the database somehow, he can then have all the passwords. If they are stored as plain text – he has them, no matter how strong. If they are stored as simple hashes, as another codinghorror article explains, password strength does not matter as well – precomputed hashes (rainbow tables) find 99% of the passwords. The solution here is simple – use salt. And let that salt be long and different for each user. If the salt is the same for all the passwords, the attacker (if determined enough), can generate a rainbow table with the given salt. It will take some time, but eventually he’ll have all the passwords. The best solution here is bcrypt.
Enough about the security aspect. Now onto usability. Complex registration forms are undesirable – they drive potential users away. Password strength indicators add to this complexity. Many users don’t actually see the point of their password being strong, because they are not web-security experts. And they are expensive usability experts – if your usability is not good enough, they just leave. I myself often leave if the password I try is considered “weak” after around 3 attempts. And a password strength indicator implies that there are at least 5-6 rules to participate in the calculation.
So, the obvious conclusion what not to do is – don’t add password strength indicators to registration forms. They are almost useless in regard to security, and add unnecessary complexity to the registration form. But what to do?
- have two rules at most, javascript-validated for immediate feedback. Length and digit+char are good options. And let the user know these rules as soon as he clicks on the password field. I’m inclined to even skip the digit+char thing, and impose a lower password length limit – say 6 symbols. Coming up with a long password is tedious. (But see the last point). There can be a 3rd rule, that the password can’t be the same as the username, but it will appear rarely. That’s enough to cover educated guesses. That’s it.
- Use TLS for login/registration (at least. Firesheep reminded us that TLS/SSL should be there more often)
- limit the number of successive login attempts (to 3 or 4 for example). Possibly warn users that there were many failed attempts.
- use salted hashes for password, with a different salt for each user
- seriously consider OpenID. If you are one of the 99% websites, that can’t say “I don’t want external login for political reasons”, go for OpenID. Users login with a single click if they are also users of the other 1 percent websites – google, facebook, yahoo, twitter, etc. Of course you can hope for becoming big, and then you can decide to store passwords yourself. But make sure you are storing them right.
Nice post bro really useful