Choosing passwords

A former college professor of mine once wrote in a slide something like: “passwords are the cornerstone of computer security”. There’s a fair bit of truth in that. Email accounts, home banking, endless forums, remote logins, subversion accounts, twitter and it’s friends, social networks, the list seems endless. This poses the question of how to manage so many credentials. The simplest of answers (and here I mean in it the naïve sense), is to use the same password for everything. Make no mistake about it: it is an incredibly stupid idea. I mean would you use the same password for your main email account and to subscribe one of those forums that asks you for an email address upon subscription, and then give you a link to go when you have “lost your password”, and when you do that, they just email you your old password, in plain text? I doubt it.

But, never mind it’s stupidity. Every single time I was asked about this, and tried to explain why it is a lousy idea, I get the same retort: yeah right, but that’s never going to happen to me, it only happens to others. I careful, I’m not stupid, I’m not going to do something stupid. And so, the inescapable conclusion is once more yielded: I’ll keep using the same password for everything. I’m secure.

No, you’re not. And I’m going to give two real life examples: one mine, the other one from Jeff Atwood, the guy behind the Coding Horror blog.

Ok, mine first. A long time ago, I was given a subversion account for a repository we used at work. And we used a web front-end to access it, viz. trac. And, you’ve guessed it, accessing trac (authentication included) was done over plain old (unencrypted) http. Nobody cared back then because, well, back them there were less then a hand full of people with subversion accounts. This one day, I finished up my task, and committed the code. Moments later, one of my colleagues shouts: “Guess who’s password just passed right in front of me!”. Yep, he happened to be debugging a piece of code using a network sniffer, and as the connection to subversion server was not encrypted, he got my password. Now I, being your all time favourite paranoid, noticed beforehand that the connection to the server wasn’t encrypted, and so I chose a password I wasn’t using for anything else. And so I dodged one more.

The one with Jeff is narrated by himself in two different posts. To make a long story short, he used an insecure password to manage a site of which he is admin (!), while also using the same password in an account for another site, which stored passwords insecurely. Somebody connected the dots, and was able to login into the admin account.

Both of these situations would have been impossible if passwords were not shared. Don’t get me wrong: the problem here is not using weak passwords for accounts with modest security requirements. The problem is sharing the password: if it’s a strong password, you’ll end up using it some place with poor password management, compromising the other accounts. And I’m not going to take the trouble of explaining why you should not share a weak password. Get a decent password management scheme (I use a variation of this) up and running, train your memory, do whatever works for you, but don’t share passwords. After all, they’re the cornerstone of computer security.

Os comentários estão fechados.