POSTS FOR 2013

Things I learned about how websites manage passwords

Privacy and Security668 words4 minutes to read

I recently wrote about the work I did to change every single password I had into ones that were unique for every site, and far more difficult to brute-force due to their long and randomized nature.

As part of this exercise, I was essentially trying to change 250 passwords on 250 websites as quickly as possible. When you do this, you end up seeing trends and patterns across unrelated sites that you might not have noticed otherwise.

Observations

Here are some of the patterns I observed about how websites manage passwords:

  1. The Login/Sign-in link is typically in the upper-right part of the global navigation bar.

  2. Very few sites support OpenID logins anymore. :(

  3. Very few sites support OAuth logins, but many will pre-fill registration forms using OAuth. We still end up with multiple accounts and multiple passwords across the board. (Missing the point, much?)

  4. I can count on 3–4 hands the number of sites I use that offer Multi-Factor Authentication options for increased security.

  5. Different companies use the words “account”, “preferences” and “settings” differently. Sometimes they use more than one of these words in their UI, and they don’t always mean the same thing for everybody. Sometimes I would log into a site and click through “preferences” and “settings” until I found where I could change my password.

  6. Some websites didn’t offer a way to change my password at all (e.g., Authy, Lockitron). In those cases, I had to pretend that I forgot my password so that I could logout and go through the “forgot password” flow to change it.

  7. Most were pretty good about telling me about success/failure of changing my password. Some didn’t say anything, so I tried again to see if it worked.

  8. The more enterprise-focused a company was, the worse its password requirements and/or tools were (e.g., Microsoft, VMware). There were a few customer-facing sites that had bad handling as well (e.g., Redbox).

  9. A surprising number of sites either offered no information about the password requirements, some information, or occasionally wrong information. It wasn’t until I tried to paste a 24-character password with special characters that some sites freaked-out. Some told me that my password was invalid, but changed it successfully, leaving me in a weird state. Some took the password and told me everything was successful, then wouldn’t let me log in again.

  10. Sites tend to make one very specific assumption: You know what your new password is going to be. I didn’t. Paypal even goes so far as to use JavaScript to disallow copy-pasting so that you’re forced to know your password, even if you don’t want to. I had to open up the Web Inspector tools to manually override this hateful behavior.

  11. As part of the aforementioned assumption, about 70% of sites require the old password while applying the new password. 30% of sites simply allow you to apply the new password since you’re already logged-in anyway. However, there are some sites which hide the “old password” field until you’ve started typing a new password. Since you don’t know what the newly-generated password is, you then need to temporarily paste it somewhere, dig up the old password, paste that, then re-copy the new password from wherever you stashed it.

  12. Some sites separate the username field and the password field by putting them on separate pages. Instead of talking about how that can actually hurt security, I’ll just say that the only sites I saw that did this were banking/financial websites (except for Simple.com, of course), and Verizon Wireless. Go figure.

Conclusion

We, as a web-building culture, have absolutely no idea what we’re doing when it comes to handling passwords. Many of us don’t understand the first thing about the balance between convenience and security. Heck, some sites are both inconvenient and insecure.

IMO, this should be the very next thing that Software Engineers and UX Practitioners work together on to solve: When you’re stuck with the “Password Anti-pattern”, how can we ensure a secure experience that isn’t cumbersome to human beings?

Ryan Parman

Ryan Parman is an experienced Software/DevOps/Security engineer, currently living in Seattle. He is the creator of and , patented multifactor-authentication-as-a-service at , and came up with the idea of “serverless, event-driven, responsive functions in the cloud” while at AWS in 2010. Ryan's aptly-named blog, , is where he writes about ideas longer than . Ambivert. Curious. Not a coffee drinker.