Categories
tech

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.

Categories
tech

First Direct Passwords

I’ve been a happy customer of First Direct since a month or so after they opened, almost twenty-five years ago.

One of the things I really liked about them was that they hadn’t followed other banks down the route of insisting that you carried a new code-generating dongle around so that you can log into their online banking. But, of course, it was only a matter of time before that changed.

A couple of weeks ago I got a message from them telling me that Secure Key was on its way. And yesterday when I logged on to my account I was prompted to choose the flavour of secure key that I wanted to use. To be fair to them they have chosen a particularly non-intrusive implementation. Each customer gets three options:

  1. The traditional small dongle to carry around with you
  2. An extension to their smartphone app
  3. No secure key at all

If you choose the final option then you only get restricted (basically read-only) access to your account through their web site. And if you choose one of the first two options, you can always log on without  the secure key and get the same restricted access.

I chose the smartphone option. I already use their Android app and I pretty much always have my phone with me.

Usually when you log on to First Direct’s online banking you’re asked for three random characters from your password. Under the new system, that changes. I now need to log on to my smartphone app and that will give me a code to input into the web site. But to get into the smartphone app, I don’t use the old three character login. No, I needed to set up a new Digital Secure Password – which I can use for all of my interactions in this brave new world.

And that’s where I think First Direct have slipped up a bit.

When they asked my for my new password, they told me that it needed to be between 6 and 10 characters long.

Those of you with any knowledge of computer security will understand why that worries me. For those who don’t, here’s a brief explanation.

Somewhere in First Direct’s systems is a database that stores details of their customers. There will be a table containing users which has a row of data for each person who logs in to the service. That row will contain information like the users name, login name, email address and (crucially) password. So when someone tries to log in the system find the right row of data (based on the login name) and compares the password in that row with the password that has been entered on the login screen. If the two match then the person is let into the system.

Whenever you have a database table, you have to worry about what would happen if someone managed to get hold of the contents of that table. Clearly it would be a disaster if someone got hold of this table of user data – as they would then have access to the usernames and passwords of all of the bank’s users.

So, to prevent this being a problem, most rational database administrators will encrypt any passwords stored in database tables. And they will encrypt them in such a way that it is impossible (ok, that’s overstating the case a bit – but certainly really really difficult) to decrypt the data to get the passwords back. They will probably use something called a “one-way hash” to do this (if you’re wondering how you check a password when it’s encrypted like this then I explain that here).

And these one-way hashes have an interesting property. No matter how long the input string is, the hashed value you get out at the other end is the same length. For example, if you’re using a hashing algorithm called MD5, every hash you get out will be thirty-two characters long.

Therefore, if you’re using a hashing algorithm to protect your users’ passwords, it doesn’t matter how long the password is. Because the hashed version will always be the same length. You should therefore encourage your users to make their passwords as long as they want. You shouldn’t be imposing artificial length restrictions on them.

And that’s why people who know about computer security will have all shared my concerns when I said that First Direct imposed a length restriction on these new passwords. The most common reason for a maximum length on a password is that the company is storing passwords as plain text in the database. With all the attendant problems that will cause if someone gets hold of the data.

I’m not saying for sure that First Direct are doing that. I’m just saying that it’s a possibility and one that is very worrying. If that’s not the case I’d like to know what other reason they have for limiting the password’s length like this.

I’ve send them a message asking for clarification. I’ll update this post with any response that I get.

Update (17 July): I got a reply from First Direct. This is what they said.

Thank you for your message dated 16-Jul-2014 regarding the security of your password for your Digital Secure Key.

Ensuring the security of our systems is, and will continue to be, our number one priority.

All the details that are sent to and from the system are encrypted using high encryption levels. As long as you keep your password secret, we can assure you that the system is secure. As you will appreciate, we cannot provide further details about the security measures used by Internet Banking, as we must protect the integrity of the system.

Our customers also have a responsibility to ensure that they protect their computers by following our common-sense recommendations.  Further information can be found by selecting ‘security’ from the bottom menu on our website, www.firstdirect.com

Please let us know if you have any further questions, and we’ll be happy to discuss.

Which isn’t very helpful and doesn’t address my question. I’ve tried explaining it to them again.

Categories
media usability web

First Direct Web Site

Here’s a good example of how not to design a user interface.

Yesterday I realised that I needed to pay my tax bill. My accountants had filed the return, it was just up to me to actually stump up the money. The deadline for payment is January 31st so it was a bit late to send the payment in by post, but I noticed that the payment slip included instructions for making an electronic transfer. It told me the sort code and the account number that I needed and told me which of the numbers on the slip I should use as the payment reference. Armed with this information I opened up the First Direct web site and found the section for making a one-off payment.

There are two routes through this section of the site. If you have all of the details that you need you can enter them directly but there’s also another route where First Direct have gathered a number (hundreds, it seems) of common payment details so that you don’t need to fill in all the numbers. That sounded like the easiest route, so I went that way. I soon found myself looking at a long list of potential payees. The problem was that their names were a bit cryptic so I wasn’t sure which one I needed. There were two that seemed to be for paying personal tax bills which were called “InlandRevCumbSelfAssessment” and “InlandRevShipleySelfAssessment”. Now Shipley is a town in Yorkshire and my payslip said that my payment should be sent to Bradford which is also in Yorkshire and “Cumb” is short for Cumbernauld which is in Scotland. So I thought I knew which one to choose but I wasn’t 100% sure. And when you’re paying taxes, it’s best to be 100% sure that you’re paying the right people.

I selected the “InlandRevShipleySelfAssessment” in the hope that the next screen would confirm the sort code and account number that were associated with this payee. But in the interest of simplification, those potentially confusing details had been helpfully left off the screen.

At that point I decided that I would be happier taking the alternative route and typing all of the required details myself. So I went back to the first page and started again. This looked better. I was given a screen that asked for all the details that I had. I filled in the details and pressed the “proceed” button. I was asked to check and confirm the details which I did. And then on the next screen it went wrong. I was told that First Direct already had those details in their system and that therefore I had to use that option and couldn’t choose to type in the details myself. Of course there wasn’t any indication of which of the list of names I should choose or (which would have been better) a link to a page that was pre-filled with those details. No, I just had to go back to my original guessing game. I chose “InlandRevShipleySelfAssessment” and hoped that it was correct.

This morning, whilst running through the process again to ensure that this description was accurate, I discovered that “InlandRevShipleySelfAssessment” has been added to my list of previously used payees. And in the list it includes the sort code and account number. So I can confirm that my tax has been paid to the right place. Which is nice, but it was all a bit of a struggle.

Let’s review the problems:

  • The list of known payees is badly organised. The symbolic names that they have been given aren’t very clear.
  • When a known payee is selected, the next screen should contain the sort code and account number for the payee, so that a user can confirm that the correct selection has been made.
  • When a user chooses to enter the details, then why not let them do that? What is the point of saying that you must use the list of known payees for a payee that is on the list.
  • If you are going to insist on a user using the list of known payees, then you can at least make their life easier by telling them which of the known payees you are talking about.

I’ve always been a fan of First Direct. I’ve been with them ever since they started up and they’ve rarely done anything that has annoyed me. Even their internet banking service generally seems a lot better than most others I haveused. But in this case it seems that their interface designers were on holiday and this part of the site was designed by someone who had never given any thought to how someone might actually want to use it.

It should be illegal to design web site interfaces if you haven’t read Don’t Make Me Think (damn, I’ve just seen there’s a second edition out…)