Password Antipattern

I’ve come across the “password antipattern” twice today. And I had different reactions to it each time. I thought it was worth trying to work out why that was.

Let’s start by explaining what I mean by the “password antipattern”. There are many bad ways to handle users’ passwords which I’ve discussed at length before, but there’s one that’s become depressingly common in recent months. And that’s the one which encourages users to give their password for some site to some completely different site in order to facilitate interaction between the two sites.

The most common example of this is when you’re trying to work out which of your friends are already on a new social networking site and the site offers to find them for you if you give it (for example) your Gmail username and password. At a time when phishing attacks are on the increase, it’s terrible that popular sites are encouraging users to treat their passwords in such a cavalier fashion.

There’s a simple rule to follow with passwords:

Never share your password with anyone else

It’s a simple as that. Your password is used to identify you to the system you are logging on to. It’s your secret. If you share it with anyone else then you can no longer be sure that you are the only person who can log into that system as you.

And it’s generally completely unnecessary. There are better ways for you to authorise one site to access your details from another. Flickr gets it right. As does Fire Eagle. Asking the user for a password is laziness.

So what were the two cases I came across today?

The first was Moo’s offer of 50 free business cards for LinkedIn users. As part of this process, obviously Moo have to satisfy themselves that you are a LinkedIn user. And they did that by asking for your LinkedIn username and password so they could try to log in as you.

In this case, I confess that I relaxed my rules and gave them the information. It’s amazing what I’ll do for a few free business cards. But I thought carefully about it before I did it. In the end, two factors persuaded me that it was a risk worth taking. Firstly, I knew that this was a one-off occurance. Moo just needed to verify my membership of LinkedIn once. There was no reason at all for them to store my password. Secondly, I trust the people at Moo. I’ve met a couple of them and many of them are good friends of my friends. The first reason persuaded me that there was no reason for them to store my password and the second persuaded me that they weren’t the kind of people who would store my password anyway.

So, yes, I broke my own rules. But it was a considered decision. And if I wanted to I could even go and change my LinkedIn password now. That won’t effect my Moo order at all.

The other case was rather different. I had seen a few people in my Twitter stream using twitterfeed to post automated messages to Twitter and I decided to investigate further. The idea is pretty simple. Twitterfeed subscribes to an RSS feed (perhaps of your blog posts) and each time a new entry is found in this feed, it posts a new message to Twitter using your username.

It’s that “your username” that scares me. Twitterfeed does this by logging in as you and posting a message. Twitter has an API, but currently the only way to authenticate as a user is to log in using their username and password. Twitter accept that this is a shortcoming and say in their documentation that they are working on an improved method.

But currently, the only way for twitterfeed to post a message to your Twitter stream is by knowing your username and password. So in order to use twitterfeed to need to give them your details and they need to store them in their database. And they need your password in plain text in order to log in as you – so they can’t store it using a one-way encryption of any kind. So a third party company has your Twitter login details in their database. It’s not a one-off thing as happened with Moo, they need to store your details for as long as you’re using their system,.

So I stopped my investigation of using twitterfeed. I’m certainly not sharing my login details with a random third party. And I strongly recommend that you don’t either. I’m currently investigating using my own tool using the Perl module Net::Twitter. But solutions like that aren’t going to be useful to everyone. Web-based services like twitterfeed are going to appeal to a lot of people.

How do we educate users to be more careful with their passwords? Or don’t we care? It is, after all, only a microblogging system. Does it matter if someone else gets hold of your details and starts sending messages as you?