If everyone followed good password advice, we’d be less secure

Passwords are hard. To be useful, they must be hard to guess. But the rules we put in place to make them hard to guess also make them hard to remember. So people do the minimum they can get away with.

Earlier this week, security company Webroot took a look at the unintended consequences of password constraints. The rules organizations set in order to ensure passwords are sufficiently complex reduce the total number of possible passwords. This can make automated password guessing more

Good passwords are easy for the user to remember and hard for computers and other humans to guess. Let’s say I wanted to use a password like 2Clippy2Furious!! Various password checking sites rate it highly. It’s 18 characters long and contains upper- and lower-case letters, digits, and special characters. But because it contains consecutive repeating letters, some companies won’t allow it.

Writing for Webroot, Randy Abrams says “it’s length, not complexity that matters.” And he’s right. That’s the point behind the “correct horse battery staple” password in XKCD #936. So let’s all do that, right?

Well…it’s not so simple. If I were trying to brute force passwords, and I knew everyone was using four (or five or six) words, suddenly instead of “CorrectHorseBatteryStaple” being 26 characters, it’s four. Granted, the character set goes from 95 to (using /usr/share/dict/words on my laptop) 479,828. “CorrectHorseBatteryStaple” is many powers of 10 more secure if the attacker doesn’t know you’re using words.

And let’s be real: they don’t. This hypothetical weakness has a long time before it becomes a real concern. Don’t believe me? Just look at the password dumps when a site gets hacked. There are a lot of really bad passwords out there. If we took all the constraints off (except for minimum length), people would just use really dumb, easily-guessed passwords again. But it amuses me that if everyone followed good password advice, we’d actually make it worse for ourselves. Passwords are hard.

Sidebar: Yes, I know

The savvier among you probably read this and thought “it’s better to use a random string that you never have to memorize because your password manager handles it for you. Just set a very long and memorable password on that and you’re good to go.” Yes, you’re right. But people, even those who use password managers, will often go to memorable passwords for low-risk sites or passwords they have to use often (e.g. to log in to their computer so they can access the password manager). 

Making secure passwords

A recent ZDNet article claimed that GPU computing has rendered even the most secure passwords dangerously crackable. It’s true that passwords developed using the conventional wisdom are subject to more easy brute-forcing, but that doesn’t mean all hope is to be abandoned. The tradeoff is normally between complexity/length and memorability, but in a “Security Now” episode earlier this month, Steve Gibson tossed that tradeoff out the window. His idea: burying your password in a haystack. The general idea is this: if your password is “r4Nd0mBunn1es”, you can make it less crackable by doing something like “/\/\/\/\r4NdomBunn1es/\/\/\/\” or “—r4ndom*****Bunn1es+++” or some other method of padding extra characters.

Even if you use the same pattern every time, so long as the password needle is different, the overall password will be very difficult to crack. So if the password is so difficult, why use a different needle for each site? Because you can’t trust the site to do the right thing. As recent attacks against Sony and other sites have shown, some sites still store passwords in plain text. At least with the password haystack, you can remember shorter passwords and apply the appropriate pattern to fill them out.

I’ve not been as quick to react to this as I perhaps should be. Admittedly, I reuse my throwaway passwords a lot, and so I’m taking advantage of this opportunity to fix this glitch. I’ll probably just create jibberish ones and save them in KeePassX.

The Terry Childs case

If you pay much attention to technical news, you probably have heard of Terry Childs.  Childs is the network admin formerly employed by the City of San Francisco who was arrested in 2008 after he was fired for insubordination and subsequently refused to give his supervisor the passwords for the FiberWAN routers.  If you know this much, you probably also heard that he was found guilty of one felony count on Tuesday.  For the sake of continuing this paragraph, I’ll assume you heard that.  Since you know this, I think it’s fairly safe to assume that your response to his conviction falls into one of two summaries: “he had it coming” and “this is an outrage.”

The prevailing mood on Slashdot and elsewhere seems to favor the latter summary.  My own take is more toward the former.  I’m not sure if that’s because I’m a short-hair type (side note: in my experience, there are two broad classifications of admins — short-hair and long-hair.  There’s often a stark behavioral/mindset difference between the two.  Maybe I’ll write about that at some point.), or if it’s because I’m still a youngin, or if it’s just because I’m being more sensible than everyone else.

My opinion on the case has softened a bit since it first broke.  Initially, the city was claiming that Childs had booby-trapped systems so that they would fail if anyone tried to gain access after he left.  As it turns out, things continued to run smoothly after Childs was fired.  There was a lot of stupid surrounding this case, and neither side comes out particularly sympathetic.  InfoWorld’s Paul Venezia had a good summary of the case in July 2008.

I don’t fault Terry Childs for refusing to give the passwords to people who asked for them, as the city had a very sensible password policy in place (don’t give user or system account passwords to anyone. The End).  What he didn’t do was put the passwords in the appropriate central repository.  I can understand his reasoning — we’ve all had incompetent coworkers that we didn’t want to share a password with, but sometimes that’s what we have to do.

Perhaps the city’s biggest mistake was letting Childs “own” the FiberWAN in the first place.  By all accounts, it was a pretty brilliant design, and every artist should be proud of the work they do, but that doesn’t make it their work.  Let’s face it: except in very rare cases, the work an admin does for his employer is the property of that employer.  We all like to think of systems as “ours”, but the reality is that we’re just caretakers, even when we design the system.  Think of a gardener as an analogue.

System/network/database/whatever-else admins have access to a great deal of sensitive information — grades in education, financial or research data in the public sector, medical records in hospitals, etc.  There is definitely a compelling need to restrict access in a sensible, responsible manner, but this must also be balanced out with a need to increase the bus factor.  There should always be at least one other person who has access to the passwords in case something unfortunate happens to the person with primary responsibility, even if this person is only authorized to get the passwords in the event of an emergency.

Childs also failed to play nice with others, and that’s the only reason we’ve heard about this at all.  Allegedly, he harassed a new manager to the point where she locked herself in a room to get away from him.  Like it or not, admins have to deal with other people, and that’s often the skill that is most lacking.  However, it is also perhaps the most necessary.  Technical position or no, we all need to be able to manage our role in office politics.  I sometimes think that should be a required class for sysadmins.  Maybe someone could set up a certification program?