I’m not a web designer, but I’ve been working in this industry since before there were web sites so I like to think I know a bit about what does and doesn’t work as far as web site usability goes. It’s mainly the stuff which doesn’t work that stands out. And there’s so much of it.
Earlier this week I was using the VirginMedia web site. Specifically, I wanted to log on to my account and download a PDF copy of my latest bill. There were three things in the process that really annoyed me. I should point out that I’m a registered user of the site, so I already had an account set up.
Username or email
The login screen asks for your username and password. That’s pretty standard stuff, of course. But when a site asks me for a username then I assume that it is going to be “davorg” (the username I’ve used on web sites for as long as I can remember). In this case, that’s not what they wanted. Your username on the VirginMedia site is your email address. Other sites use email addresses as your username, but in most cases they then label the field as “email”. Labelling it as “username” adds an unnecessary complication. I gave them my username and, as it was incorrect, the error message pointed out that my username would, in fact, be my email address. So they recovered from the problem well, but there was a moment or two of unnecessary frustration.
Limited length passwords
Having established what my username was, my next problem was remembering my password. I tried a few likely candidates and, eventually, resorted to the “forgot my password” link. That sent me an email containing a link to a page where I could set a new password. And that’s when I remembered why I had forgotten the original password.
VirginMedia have strange limits on what can go in your password. They have the usual stuff about having both letters and digits in your password, but they also have a maximum length of ten characters. That’s why I couldn’t remember it – most of my standard passwords are longer than that. It seems strange to restrict users to such short passwords.
It’s worrying in another way too. If you’re following best practice for dealing with users’ passwords then you won’t be storing the password in plain text. You’ll have some encrypted version of the password. And many of the popular encryption algorithms (for example, MD5) have the property that no matter how long the text that you start with is the “hashed” version will always be the same length. So you create a database column of that length and you don ‘t need to restrict your users at all. Having this restriction isn’t conclusive proof that they’re storing plain text password, but it’s enough to worry me slightly.
Naming downloaded files
Having (finally) logged into my account it was easy enough to find the link to download my current bill. And within seconds I had the file on my computer. But the file was called “GeneratePDF”. And when I come to download next month’s bill that will also be called “GeneratePDF”. What has happened here is that GeneratePDF is the address in their web site that is used to.. well… generate PDFs. And in the absence of other information, browsers will name downloaded files using the address that they came from. It’s easy enough to change that default behaviour using the content-disposition header. Using this header it would be easy to tell my browser to save the downloaded file as, for example, vm-2011-05.pdf. Anything would have been more useful than the current set-up. Notice that the current name doesn’t even have a ‘.pdf’ extension so it’s likely that on some computers double-clicking the downloaded file won’t open in the the user’s PDF-reading software.
So there you have three things that annoyed me about the VirginMedia site. And the really annoying thing is that two of them (the first and third) are really trivial to fix. The second is probably harder to fix, but it’s possibly evidence of some rather broken design decisions taken early in the process of developing this web site.
I tweeted these three issues on Wednesday and I got a response from the virginmedia Twitter account saying “Ok, some fair points there. Will feed this back for you, thanks for taking the time to let us know!” I’ll be downloading my bill every month, so I’ll let you know if anything gets fixed.
While I very much agree that in modern applications forcing passwords to be at most 10 characters is wrong, and that plain-text passwords are evil, there are three issues which may be at work here which were recently discussed on the Web Security mailing list.
A brief summary of the points:
1) Legacy systems suck. It’s pretty easy to believe that a much more limited system is still in use at an large ISP and that integration is an issue, so passwords must be kept short. This costs (potentially quite a lot of money which would have to be recouped somehow) to solve, and if passwords limited to 10 characters are, after a risk assessment, discovered to be secure enough, it may be a better decision to simply take that risk.
2) Hashing massive volumes of data can be expensive, so picking an upper limit to the input size has to be done. Consider also that the has function designed to hash your password should be slow and if possible should take up a lot of memory and CPU and suddenly large numbers of large passwords become a very feasible operations issue.
3) There’s a possible human factor here. I doubt this one is very likely, but where it’s possible to enter longer passwords it could also be possible that users feel more secure typing longer passwords… and then writing them on pieces of paper that they leave under their keyboards. It’s possible to reduce the incidence of this behaviour by limiting password size.
Hello Dave. I see that you write quite a few useful posts on these kind of issues. I think it’s time you put together a more formal list of all these points that developers could refer to as a sort of checklist. This would be very useful for people. Ian.