Alright Internet, we need to talk.

You’ve grown up quite a bit over the last several years, but I’ve never taken the time to have the talk with you. You know the one. The safe passwords talk.

Your requirements for a minimum length, and a diversity of characters in passwords made many classes of brute force attack more difficult. You’ve gotten a bit carried away though, it seems. You’re actually making the internet a more untrustable place.

###The Problem### I ran into this while trying to reprovision a server[^1]. The password in question? “2674x0F>4dabvsC”, created with a simple password generators.

Why put a MAX on my password length?

Eight to 14? A lower limit of eight totally makes sense, but a maximum of 14? Okay, that’s annoying, but whatever. Let’s lob off the last character.

Yes, I know there aren't 14 dots.

Must begin with a letter? Now I’m annoyed. Yes, I’m being pedantic, and I’ll certainly concede that it’s a tiny thing to get riled up about, but let’s take a second to look at it.

###Trust### As a developer, red flags started going up after the first warning. By the second one, my brain was into the lower DEFCONs. Why? My brain tries to find meaning behind every action. It tries to find the cause for every effect. It’s what makes me good at debugging. It’s what makes a bad time travel story intolerable. It’s a ridiculously useful trait, and now it’s being pitted against me: I’ve got to accept that the restrictions are either arbitrary or that no one could figure out how to deal with passwords starting with a number. I have to accept that the group behind the form was either irrational, or inept. Either way, it makes it difficult to trust them.

Brought to you by the highly insecure number 2!

If the password system could be foiled by the same kind of character that brings us episodes of Sesame Street, how am I supposed to expect that the people implementing the system knew about salts and hashes? The backend infrastructure might be highly secure, but all I know is that the front end system wants me to drop the amount of entropy in my password, presumably because the backend can’t handle it. Secure or not, all I can imagine at this point is unsalted MD5s and that the server probably doubles as an anonymous FTP server. Oh, and that it probably still runs Windows 2000.

Yeah, it makes it hard for me to trust.

###Friction### Most people aren’t developers though. They aren’t worried about the hash being used. They just want their service to work, and tend not to think about password security. And quite honestly, I can’t blame them. The average person isn’t aware that computers can be programmed to automate login attempts. They picture a guy sitting in his basement manually trying each password.

So here’s the rub: it takes effort to behave securely, and the more it takes, the less likely people are to do so. We’ve seen an entire class of product spring up just to remove the friction that keeps people from behaving safely. Even my browser has joined the game1. These password managers are one way we get people to stop using “MrWhiskers1” as their passwords. This is the root of my frustration: arbitrary rules increase the effort while simultaneously lowering the effectiveness of our tools.

My friends call me Jimmy FakeAccount

Take a look at the above password Safari wanted to generate for me: 15 characters, and it happens to start with a number. That’s two strikes against it. My suspection is that the average user won’t tweak the password to make it fit the rules. I suspect that they’ll see that it “didn’t work” and then fall back on old habit.

An examination of over 30,000 compromised MySpace passwords found that the average password was 8 characters long and had over a 3 in 4 chance of starting with a letter2. Maybe they’ll use one of those. They do fit the ruleset, after all. Or maybe they’ll just fall back on using “password”. It’s such a laughably bad choice, but it was actually the third most commonly used in a set of 150 million leaked accounts from Adobe.

###Conclusion### I guess that’s the core of my frustration. We start out on the wrong side of the fulcrum. We’ve been given a stick and a pivot, but the setup is wrong. We have to expend large amounts of energy in order to encourage people to form better habits, but only a little friction is required to undo it.

It disappoints me a bit. We place the onus on the end user to understand what makes a good password when we really should do the work ourselves. That is our domain, not theirs. We could suggest a password for them, show them a phonetic representation of their password, or just link to a password generation site. Or we could link to a password manager that they can use. If nothing else, we could show a stock “password strength” bar. Certainly not encourage shorter and easier passwords though.

Arbitrary rules don’t increase security, just difficulty. They make it harder for me to trust the developers on the other end of the plumbing, and they train people not to use their tooling. They train people to fall back on Post-Its loosely dangling from their monitors. And somehow that cost is acceptable, even with no benefit.

###Footnotes### [^1]: cough GoDaddy cough. Seriously GoDaddy, you manage a decent portion of the sites on the internet. You shouldn’t be the poster boy for amateur hour. It’s not only embarrassing, but just a bit terrifying.

  1. The argument could easily be made that Safari’s feature is more of an attempt to cause casual platform lock-in with OS X and IOS. Motivation aside, the results are what I’m focusing on. 

  2. Research paper “Password strength: an empirical analysis” p3. (download) (ACM Library