First Direct Update

Earlier in the week I talked about my concerns with First Direct’s new password policy. I got an email from them about this, but it really wasn’t very reassuring.

But I kept digging. And on Thursday I got a bit more information from “^GD” on the @firstdirecthelp twitter account. It still doesn’t answer all of my questions, but I think we’re a lot closer to the truth. Here’s what I was told.

The obvious question that this raises is why, then, do they limit the length of the passwords. I asked and got this (three-tweet) reply.

To which, I replied

And got the response

I thought that “as a business we are satisfied” rather missed the point. And told them so.

I got no response to that. And @brunns got no response when he tried to push them for more details about how the passwords are stored.

So, to summarise what we know.

  • First Direct say they store the passwords “encrypted”, but it’s unclear exactly what that means
  • It was a business decision to limit the length of the passwords, but we don’t know why that was considered a good idea
  • It still appears that First Direct believe that security by obscurity is an important part of their security policy

I haven ‘t really been reassured by this interaction with First Direct. I felt that the first customer support agent I talked to tried to fob me off with glib truisms, but “^GD” tried to actually get answers to my questions – although his obvious lack of knowledge in this area meant that I didn’t really get the detailed answers that I wanted.

I’m not sure that there’s anything to be achieved by pushing this any further.


Free Web Advice: Marvel

It’s been a few years since I wrote a “free web advice” piece, but I got really annoyed by the Marvel web site this morning.

About a year ago I subscribed to Marvel Unlimited – a plan that gave me access to all of Marvel’s digital comics for about £40 a year. This morning, I got an email from them saying that my subscription was about to be renewed but that my credit card had expired so I should log on to my account and update my credit card details.

I went to log on and found that I had forgotten my password. So I used the “forgotten password” link expecting to get an email containing a link I could use to reset my password. Instead, I got an email that contained both my username and my password in plain text. If Marvel are able to send my password to me, then they must be storing everyone’s password in a readable format. It’s astonishing that a company the size of Marvel don’t understand just what an incredibly stupid idea that is. And sending both my username and password in the same email just compounds their error.

So that’s strike one – storing plain text passwords.

Having recovered my password, I was able to log on and found the page where I could give them my credit card details. But it looked like this:

Marvel Credit Card Maintenance Page

If you look closely, you’ll see that three fields – credit card type, expiration date and country – have captions, but no way to enter the required data. I’ve tried this page in both Firefox and Chrome and get the same results in both. I expect I’ll have to dig out a PC running Windows and try it on Internet Explorer as well.

I didn’t actually notice the missing fields at first. I just filled in the fields I could see and submitted the form. At that point I got an error pointing out what was missing. It’s interesting to note that the credit card type isn’t marked as required on the form (there’s no red asterisk next to it) but the error I got complained that it wasn’t filled it.

So that’s strikes two and three.
Strike two – always ensure that your web pages work on all the popular browsers.
Strike three – always mark your required data inputs accurately.

At that point I gave up trying to give money to Marvel. I poked around the site for a while to find a contact form. When I found it, it had the same problems as the credit card form – most of the input fields didn’t appear. Luckily, the contact page also gave an email address (that’s a really good idea that most web sites don’t follow). So I used that to report the problems. I’ll update this post if I get a response.

Interestingly, on my account page I was also given the option to upgrade my account. Apparently Marvel and I disagree on the meaning of the word “unlimited”. It’s not clear to me what extra benefits I could expect.

Update (four months later): Somehow, Marvel managed to renew my subscription, even though I never managed to update my credit card details. But bizarrely, this evening (over four months after writing to them) I got a reply from Marvel’s customer support. It said this:

Thank you for contacting Marvel’s Online Support services. We apologize for the delay in getting back to you. We see that you were able to renew your subscription, after contacting us. If you have any further questions, please do not hesitate to contact us. Thanks again for contacting Marvel.

Four months to reply to a simple customer support message must be some kind of record.


Internet Security Rule One

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.

It’s called the Password Anti-Pattern and its shortcomings have been well-documented for several years. I wrote about it with specific reference to Twitter a few years  ago.

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.


Twitter Supports OAuth

I’ve been seeing various announcements and trials over the last few weeks, but it seems that the wait is over and Twitter finally officially supports OAuth. This means that there is no longer any reason for third party web sites to store your Twitter password if they want to interact with Twitter on your behalf. This closes a security hole that I’ve been going on about for months.

Well, except, the security hole hasn’t actually been closed. The third party applications still have the option to use the old authorisation mechanism. It wouldn’t, of course, be fair for Twitter to force all of the third party applications to change their authorisation code overnight. Twitter say:

There is no requirement to move to OAuth at this time. If/When a date is set for the deprecation of Basic Auth we will publish a notice on the API Development Talk. We will not set a date for deprecation until several outstanding issues have been resolved. When we do set a date we plan to provide at least six months to transition.

So you can still use the old, and broken, authorisation mechanism. But over the coming days and weeks we should see fewer and fewer applications using it. And there’s no excuse at all for new applications to use it.

I’m looking forward to using some of the Twitter add-ons that I’ve been avoiding for security reasons. I’ve already turned on Twitterfeed (which, as far as I can see, was one of the first applications to make the switch) and I’m planning to take closer look at just as soon as they switch over.

As a user of these applications there are a couple of things that you can do.

  1. Check the services that you are using to see if they have switched to using OAuth. You’ll know if they have as you’ll know longer be prompted to enter your username and password. Instead you’ll be shown a page on the Twitter site and asked to authenticate the application to interact with Twitter on your behalf.
  2. If your services have switched to using OAuth then do what ever you need to do in order to stop using the old mechanism. I can’t really explain what form that might take as I’ve never had to do it. Then change your Twitter password so that your current password isn’t still in someone’s database in plain text.
  3. If services that you use haven’t switched to using OAuth yet, then give the developers a gentle prod and tell them that you’ll be far happier using their service once they’ve made the change. Maybe even tell them that you’ll stop using their service until they’ve made the switch.

I’ve been quite harsh in my criticism of Twitter for encouraging this horrible antipattern to become so acceptable across the internet. I still think that it was a terrible design decision on their part and that they have taken longer than necessary to respond to the criticism they have received from several people. But I’m glad that they’ve now introduced OAuth and I hope that we can all do all we can to assign the old-style authenication to the dustbin of history as soon as possible.


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?


Hating Computers

Right now I’m hating all computers with a fierce intensity.

You all know about the server disk crash. I’m still dealing with the fallout from that. In addition to that, on New Year’s Day I upgraded my main desktop machine to Fedora 8 – with the result that the wireless network (which is how that machine talks to the internet) no longer works.

Then, when I got back to work yesterday, the security policies forced me to change my password. And for some reason, that change still hasn’t synced through to all of the systems. This means that I have spent half of today typing the wrong password. And the other half resetting my password because I’ve been locked out of systems for typing too many wrong passwords.

And I think this cold is focussing my hate in a most distressing manner.


Password Basics

I’ve banged on before about the need for web sites to store passwords encrypted. This is a good example of why it’s necessary.

Fasthosts, “the UK’s number 1 web host”, has fired off emergency emails telling customers to change all their passwords after police were called in to investigate a major data breach.

Also note:

We’ve asked Fasthosts why the passwords were not encrypted in the first place. It said: “Historically, Internet companies have rarely encrypted passwords to aid customer service.”

Hmm…. “aid customer service”? Not sure that rings true. Particularly when someone breaks into your systems and gains access to your customer database. If the passwords were encrypted then they would still be secret.

Of course, there are many other good reasons for not using Fasthosts.

If I had any sites hosted with them, I’d be moving them away very quickly right now.

Update: From the Register’s discussion on this story:

Any developer worth his salt wouldn’t make such a hash of this.

Nice bit of geek humour.


Basic Password Handling

This afternoon I signed up to a new web-based application from a very well-known media company. I gave them my email address and the password that I wanted to use and a few minutes later I got an email from them confirming my registration.

That was fine. But then I noticed that the email from them contained the name of their site, my username and my password. All in plain text. This is a breach of basic internet security processes. And thinking about it, I’ve seem several similar breaches recently. So I thought it was worthwhile making a note of some of the rules you should be following when handling users’ passwords on web sites and in emails. A sort of “Password Handling 101”.

Rule 1: Don’t Store Plaintext Passwords

This is the fundamental principle that all the other rules follow from. It is non-negotiable. If I give you a password to use on your web site then I should be the only person who knows it. I don’t want it stored unencrypted in your database so that any of your staff can look it up.

“But,” you say, “if it’s encrypted, how can we check it against the password you give us when you log in?”

“Easy,” I reply, “you do it the same way that Unix passwords have been checked for decades.”

You store the password using some encryption algorithm. The stronger the better. Then when I give you a password for you to check, you encrypt the new password using the same algorithm and compare it against the encrypted version in your database. If the two encrypted strings match then I’ve given you the correct password and you can log me in. Simple isn’t it?

“But,” you say, “if it’s encrypted, how can we tell you what it is if you forget it?”

“Simple,” I reply, “you don’t.”

If I forget my password then you have two options. Option one is that you generate me a new password, email it to my registered email address (but see rule 2 below) and store an encrypted version of the new password in your database. Option two is that you send (to my registered email address) a link to a web page where I can enter a new password. This link should obviously be time-limited (so I can only use it for a few hours) and should contain some encrypted key so that no-one can guess what the link is. The second option is less secure as anyone can intercept the email and get access to the link, so the first option should be preferred.

Rule 2: Username and Password Travel Separately

The problem with internet email is that (unless you use something like GPG) everything is in plain text and anyone can intercept it and read it. It’s like you are sending every letter on a postcard rather than in an envelope. For this reason you should never put the username and the password in the same email. The forgotten password scenario above should be the only reason why you ever send a password to a user in an email. So don’t put the username in that email as well.

Rule 3: Web Pages with Passwords Should Use HTTPS

Like email, by default, all web traffic is unencrypted. Anyone can potentially read anything that you send to a web site. So when I log on to your site and I enter my username and password, anyone can potentially intercept those values and that will enable them to log on to your site as me. If you serve login pages using HTTPS instead of just HTTP then that login transaction will be encrypted all the time the data is on the public internet and it will be much harder for anyone to extract my login details.

Three simple rules that every web site should be following. And it’s surprising (or, at least, it surprises me) how many sites don’t follow these basic rules. Following these rules won’t make your site impervious to people determined to break into in, but it will go a long way to making your users’ accounts more secure.

I was going to name and shame the site that I dealt with this afternoon, but I wrote them a polite email explaining the problems and in less than 45 minutes I got a reply saying that these problems had already been noted and that they should be fixed by the end of the week. That’s pretty good customer service so I won’t embarrass them by telling everyone who they are.