Internet security rule one is “do not share your password with anyone”. There should be no exceptions to this rule. If anyone asks you to share your password with them, your answer should always be no.
Sometimes people say “oh well, it’s only a password for [some unimportant web site] – what harm could it do?” And, of course, perhaps giving someone your password for that particular unimportant web site won’t do any harm. But it’s a chink in your armour. By revealing your password for that site you’ve set a precedent. You just might be that little less protective the next time that someone asks you to share your password.
There are two levels of problem here. Firstly there’s the fact that you’ve given a third party complete access to interact with the web site for you. If it’s your Twitter password you’ve given away then the third-party service can do anything to your Twitter account that you can do yourself – right up to closing your account.
I assume that everyone can work that out for themselves. But the second problem is more subtle. Obviously any web site where I have an account is storing my password somewhere (probably in a database). And any third-party service that I want to share my password with also stores that password. So what’s the difference?
The difference is that the original web site is (hopefully) following basic password storage principles and storing my password using non-reversible encryption. The third-party site can’t do that. The third-party site needs access to the plain-text version of the password so it can be used to log on to the original web site. Oh, sure, they’ll hopefully store the password in their database in some encrypted format, but it will have to be a reversible encryption so that they can get a plain-text version of it back when they need to use it to log in to the original site.
So if someone somehow gets a copy of the original web site’s database, your password is held in some industrial-strength non-reversible encrypted format. But if they get a copy of the third-party service’s database, they’ll have your password in a far less secure format. If, at the same time, they manage to grab the third-party service’s source code then they’ll know exactly what process to follow to get the plain-text version of your password from the encrypted version.
Of course, you’d hope that their data centre is secure and no-one will ever steal their database or their source code. But it could happen. And the more passwords that you share, the more chance there is that someone, somewhere will get hold of data that you’d rather not have.
There is, of course, a way round this. It’s called OAuth. With OAuth, you don’t need to give anyone your password. You can authorise certain applications (or services) to take certain actions on your behalf on particular web sites. So, for example, I can let Twitterfeed post to my Twitter account without giving it my password. And that’s all it can do. It can’t follow new people, maintain my Twitter lists or close my account.
Twitter is a good example. In 2007 and 2008 a whole ecosystem grew up around Twitter. Many services offered cool and interesting services to add on to your basic Twitter account (Twitterfeed was one of them). But they all needed your Twitter username and password, so anyone who was at all security-conscious couldn’t use them. But in 2009 Twitter implemented OAuth. And, a few months later, they turned off the old authentication scheme so that you now only use OAuth to talk to Twitter.
The remaining problem is that OAuth only works when the original web site has implemented it. And that’s quite a lot of work. There are still many web sites out there which have lots of useful information out there locked behind a username and password with no other way to access it.
All of which brings me to what prompted this post. Earlier today a friend pointed me at a web site which provided a really useful service. But when I looked, it did it by asking for my login details for another web site. I’m not going to name either of the sites involved (my friend works for the third-party site and I don’t want to embarrass her), but it was a really useful service and it made me sad that I couldn’t use it.
Of course, as my friend explained, they had no alternative. The original site didn’t have OAuth support, so the only way they could get hold of the useful data was to log in as the user.
To my mind, that’s not a good reason for implementing the password anti-pattern. To my mind that’s where you say “oh well, that was a good idea – shame it’s not going to work” and start to lobby the original web site for some kind of OAuth support. But that’s not likely to happen as the point of this service is to compare different offerings and make suggestions of how the user could save money by switching to competitors. I can’t really see the original companies being keen to support that.
So we’re left with a situation where this third-party has implemented the password anti-pattern. And, as far as I can see, they’ve made quite a nice little business out of it. But makes me really uncomfortable to see what they’re doing. I’m pretty sure that I can trust them with my data, but I’m not prepared to compromise my principles in order to access this useful service. They are teaching people that it’s okay to share their passwords. And it’s not. It never is.
And it doesn’t stop with this company promoting their own service. On their site they have testimonials from a number of well-known web sites, newspapers and television programmes saying what a wonderful service it is. They have technology correspondents, who I would expect to know better, singing their praises and encouraging people to sign up for the service – telling people to break the first rule of internet security.
It all makes me rather depressed.
Look, I’ll tell you what. I’ve got a really good idea for an add-on for your online banking service. Just leave the login details in a comment below and I’ll set it up for you.