5 Myths of Password Security
Originally posted by Brent Jensen
High profile database breaches aren’t a daily thing just yet, but they’re certainly not rare. Linode’s recent system-wide password reset and Scribd’s account compromises were announced just nine days apart. In the last week, there have been breaches at LivingSocial and Reputation.com. Pay attention to the e-mails sent after hacks like these, and you’ll notice they often come with a set of new password recommendations. Password best practices are something Stormpath has already covered in depth, but always from a backend perspective.
So, instead of cautioning against hashing with MD5 again (seriously though, don’t do it), we wanted to take a look at some of the more insidious password myths we run into. We hope this helps developers create smart password policies, which we will shamelessly mention you can set automatically if you use Stormpath.
1. MYTH: Complexity Trumps Length
The truth here is that password security depends heavily on the attack method. Dictionary attacks can crack different passwords than brute-force attacks. People often think of a short set of random characters like “*K>#)0$j4” as super secure, but a long string of memorable words like “golfkangaroocrispyhalitosis” is actually stronger.
The reason has everything to do with password entropy: a representation of how much uncertainty there is in a password. This translates to how computationally difficult a password is to crack. Simply put, adding length increases entropy more efficiently than replacing letters with symbols.
It is also important for users to use random text in passwords, like ‘golf kangaroo crispy halitosis’, which is comprised of words with no obvious correlation. Using people’s names, repeating characters, sequential numbers or well-known keyboard entries like `qwerty` are expected – the opposite of random.
We recommend the intrigued reader check out this great blog post for a deeper explanation on password entropy, or XKCD’s notorious (and amazing) comic for quicker reference. When enforcing passwords or giving guidance to your users, prioritize length and random text over character complexity. Better yet, aim for both.
2. MYTH: Big Companies Store Passwords Securely
50% of web apps store credentials unencrypted. As in plain text. As in someone who gains access to the app’s database can simply read the passwords. LinkedIn is about as legitimate as companies come, but they weren’t following basic best practices (namely, not using a salt) before their breach last year. Users should use a unique password everywhere, and on account creation screens, you can remind them to do so. Not only does it help the user, it also means someone else’s weak hash won’t have an effect on your system.
3. MYTH: Password Checkers Ensure Strong Passwords
Stormpath uses password strength enforcement on our own registration form, and it’s available to use through our API. It’s absolutely a useful mechanism, but not all password checkers are created equal.
Password strength checkers use custom “security criteria” to assess a password, and a minimum score may be required to finish registration. There are two common methods for calculating these scores: measuring the entropy of the password (often represented as ‘time to crack’) or comparing it against a set of benchmarks. In addition to length, common benchmarks include whether a password contains numbers, mixed case letters, or special characters.
Microsoft’s secure password checker and The Password Meter are two popular third party options. Both are useful tools, but they’re not substitutes for best practices. Less-than-stellar passwords can score high:
| Password | Microsoft | The Password Meter |
|---|---|---|
| jjjjjjjjjjjjjjjjjjjjjjjjjjjj | Best | Very Weak |
| Jessica1234567 | Strong | Very Strong |
| Qwertyabc123 | Strong | Strong |
For instance, a string of the letter ‘j’ should not receive top marks, even with its high entropy value. An attacker can too easily repeat one character the maximum number of times a login form allows. Does combining ‘Jessica’ and ‘1234567’ make for a Very Strong password? They were among the most common passwords in the massive RockYou breach. The same goes for ‘Qwertyabc123’, which both tools mark as Strong. Blacklisting common passwords is difficult to bake into a password checker (our own form would block the first password above and allow the second two), but they’re easy for an informed user to consider.
Keep in mind that we’ve been assuming a solid implementation of the checker. Unfortunately, scoring criteria are often weak (i.e. 6 character minimum), based on outdated assumptions, or simply nonexistent. Overall, these enforcement algorithms provide improved security to the majority of users. However, their inevitable weaknesses mean they should be viewed as an added bonus and never as a reason to settle for weak encryption.
4. MYTH: Two-Factor Auth Means Any Password Will Do
Two–factor authentication is like every other system in at least one regard: flaws will be found. Last year, CloudFlare CEO Matthew Prince wrote up a detailed account of the hack that gained access to his Email account. The kicker? He had already implemented two-factor authentication—the attacker got around it.
This is absolutely not a dismissal of multi-factor auth. Use it when it’s available! Two factor is on the Stormpath roadmap, and we use it for many backend systems. Just don’t consider it a substitute for strong passwords.
5. MYTH: CAPTCHA Keeps Accounts Safe
Two major weaknesses make CAPTCHA a poor choice for preventing brute-force login attempts. First, it’s difficult for users. Second, most implementations aren’t sufficiently secure. CAPTCHA has the unenviable task of finding that sweet spot where it can fool ever-improvingattacks without introducing significant friction to the login process.
Stanford University conducted an interesting study examining just how effective CAPTCHA is at minimizing that friction. A few takeaways:
- 3 people looking at the same CAPTCHA agreed on the reading just 71% of the time.
- Average time to solve a text-based CAPTCHA = 9.8 seconds.
- 3 people listening to the same audio CAPTCHA came up with the same value only 31.2% of the time.
- Average time to solve an audio CAPTCHA = 28.4 seconds.
- Time to solve was even longer for Non-native English speakers
That’s a lot of annoyance from a user standpoint, and if usability for usability’s sake isn’t enough, CAPTCHA really does cause users to bounce. The percentage of users who give up in frustration varies, but figures of 20% have been reported. It should be noted that some of these are likely the bots CAPTCHA is intended to thwart.
To cap it all off, most CAPTCHA schemes are quite breakable. There’s a vibrant economyaround doing just that. More secure implementations are forced to engage in constant escalation to stay that way—resulting in more difficult CAPTCHAs. At the end of the day, we don’t recommend CAPTCHA for protecting against account hijacking.
Bonus Myth: Passwords are dead! Long live (insert favorite authentication method here)! See:http://www.stormpath.com/blog/long-live-password
