Financial Account Aggregation

Three years ago, I wrote a blog post entitled Internet Security Rule One about the stupidity of sharing your passwords with anyone. I finished that post with a joke.

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.

It was a joke because it was obviously ridiculous. No-one would possibly think it was a good idea to share their banking password with anyone else.

I should know not to make assumptions like that.

Yesterday I was made aware of a service called Money Dashboard. Money Dashboard aggregates all of your financial accounts so that you can see them all in one convenient place. They can then generate all sorts of interesting reports about where your money is going and can probably make intelligent suggestions about things you can do to improve your financial situation. It sounds like a great product. I’d love to have access to a system like that.

There’s one major flaw though.

In order to collect the information they need from all of your financial accounts, they need your login details for the various sites that you use. And that’s a violation of the Internet Security Rule One. You should never give your passwords to anyone else – particularly not passwords that are as important as your banking password.

I would have thought that was obvious. But they have 100,000 happy users.

Of course they have have a page on their site telling you exactly how securely they store your details. They use “industry-standard security practices”, their application is read-only “which means it cannot be used for withdrawals, payments or to transfer your funds”. They have “selected partners with outstanding reputations and extensive experience in security solutions”. It all sounds lovely. But it really doesn’t mean very much.

It doesn’t mean very much because at the heart of their system, they need to log on to your bank’s web site pretending to be you in order to get hold of your account information. And that means that no matter how securely they store your passwords, at some point they need to be able to retrieve them in plain text so they can use them to log on to your banks web site. So there must be code somewhere in their system which punches through all of that security and gets the string “pa$$word”. So in the worst case scenario, if someone compromises their servers they will be able to get access to your passwords.

If that doesn’t convince you, then here’s a simpler reason for not using the service. Sharing your passwords with anyone else is almost certainly a violation of your bank’s terms and conditions. So if someone does get your details from Money Dashboard’s system and uses that information to wreak havoc in your bank account – good luck getting any compensation.

Here, for example, are First Direct’s T&Cs about this (in section 9.1):

You must take all reasonable precautions to keep safe and prevent fraudulent use of any cards, security devices, security details (including PINs, security numbers, passwords or other details including those which allow you to use Internet Banking and Telephone Banking).

These precautions include but are not limited to all of the following, as applicable:


  • not allowing anyone else to have or use your card or PIN or any of our security devices, security details or password(s) (including for Internet Banking and Telephone Banking) and not disclosing them to anyone, including the police, an account aggregation service that is not operated by us

Incidentally, that “not operated by us” is a nice piece of hubris. First Direct run their own account aggregation service which, of course, they trust implicitly. But they can’t possibly trust anybody else’s service.

I started talking about this on Twitter yesterday and I got this response from the @moneydashboard account. It largely ignores the security aspects and concentrates on why you shouldn’t worry about breaking your bank’s T&Cs. They seem to be campaigning to get T&Cs changed so allow explicit exclusions for sharing passwords with account aggregation services.

I think this is entirely wrong-headed. I think there is a better campaign that they should be running.

As I said above, I think that the idea of an account aggregation service is great. I would love to use something like Money Dashboard. But I’m completely unconvinced by their talk of security. They need access to your passwords in plain text. And it doesn’t matter that their application only reads your data. If someone can extract your login details from Money Dashboard’s systems then they can do whatever they want with your money.

So what’s the solution? Well I agree with one thing that Money Dashboard say in their statement:

All that you are sharing with Money Dashboard is data; data which belongs to you. You are the customer, you should be telling the bank what to do, not the other way around!

We should be able to tell our banks to share our data with third parties. But we should be able to do it in a manner that doesn’t entail giving anyone full access to our accounts. The problem is that there is only one level of access to your bank account. If you have the login details then you can do whatever you want. But what if there was a secondary set of access details – ones that could only read from the account?

If you’ve used the web much in recent years, you will have become familiar with this idea. For example, you might have wanted to give a web app access to your Twitter account. During this process you will be shown a screen (which, crucially, is hosted on Twitter’s web site, not the new app) asking if you want to grant rights to this new app. And telling you which rights you are granting (“This app wants to read your tweets.” “This app wants to tweet on you behalf.”) You can decide whether or not to grant that access.

This is called OAuth. And it’s a well-understood protocol. We need something like this for the finance industry. So that I can say to First Direct, “please allow this app to read my account details, but don’t let them change anything”. If we had something like that, then all of these problems will be solved. The Money Dashboard statement points to the Financial Data and Technology Association – perhaps they are the people to push for this change.

I know why Money Dashboard are doing what they are doing. And I know they aren’t the only ones doing it (Mint, for example, is a very popular service in the US). And I really, really want what they are offering. But just because a service is a really good idea, shouldn’t mean that you take technical short-cuts to implement it.

I think that the “Financial OAuth” I mentioned above will come about. But the finance industry is really slow to embrace change. Perhaps the Financial Data and Technology Association will drive it. Perhaps one forward-thinking bank will implement it and other bank’s customers will start to demand it.

Another possibility is that someone somewhere will lose a lot of money through sharing their details with a system like this and governments will immediately close them all down until a safer mechanism is in place.

I firmly believe that systems like Money Dashboard are an important part of the future. I just hope that they are implemented more safely than the current generation.



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,

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.


Twitter and Passwords

Over the last year or so, Twitter has become one of the most successful social networking sites on the web. One mark of its success is the rich ecosystem of other sites which feed off it. The best example is probably the Twitter search engine which started as a separate web site but was so successful that it was bought by Twitter and integrated into the main site.

There are many other sites that also provide tools to improve your Twitter experience. Unfortunately a large proportion of them encourage users to break one of the fundamental rules of internet security. Even more unfortunately, it seems that most users don’t understand internet security and the sites are therefore thriving when they should be ignored.

What is this basic rule of internet security that these sites are breaking? They are asking for your Twitter username and password.

Your password for any particular service should always be a secret between you and that service. No-one else should ever need it. In fact if you read my piece about basic password security from a few years ago, you’ll know that the service shouldn’t store the plain text version of your password. Only you should know that.

I don’t understand why people are so willing to give anyone their Twitter passwords. Well, I suppose I do. The services that are offered are so shiny. I’d love, for example, to use Twitterfeed. But I can’t because it requires me to give over my password to someone else.

It’s not that I don’t trust the owner of Twitterfeed to do the right thing. It’s that I know it’s completely impossible for him to store the password as securely as it should be stored. Think about it. Twitterfeed needs your password each time it posts something to Twitter under your name. That means that it can’t use the non-reversable encryption that a sensible service uses for storing passwords. At best they use a reversable encryption method. At worst they store it in plain text.

Clause 3 of the Twitter terms of use says:

You are responsible for keeping your password secure

If I give my password to another site, I can’t do that. I’m sharing the responsibility for keeping my password secure with other people.

There are, of course, other people who share my concerns. You’ll see the occasional debate on this subject on places like Get Satisfaction. But I’m amazed by the number of people who should know better but still use these systems. A few weeks ago, Charles Arthur (The Guardian’s technology editor) wrote a piece on this subject. He talked about a site called TwitterRank which gave you some meaningless statistics about your place in the Twitterverse in when you gave it your username and password. Charles rightly advised people not to give their password to random web sites. But I knew that he had written the article because his Twitterfeed account posted details to his Twitter stream. When I pointed out the irony in a comment he seemed to miss the point.

How many otherwise intelligent people do you know who use Twitterfeed? Or other systems like Over the weekend, Robert Scoble praised a site called PeopleBrowsr on his blog without bothering to point that it would ask for your Twitter password and what a bad idea that might be.

There are two arguments that people seem to use to defend these kinds of service. The first is that “it’s only your Twitter password”. And that’s true of course. The world wouldn’t end if someone got my Twitter password and started to send messages pretending to be me. But by promoting this way of doing things, it becomes more likely that people will be less protective of their passwords. How many sites have you seen that offer to tell you if your friends are signed up if you give them your Gmail username and password?

The other argument I often here is that the services are really useful and that Twitter don’t support any other way of doing the things that these services want to do. Well, I don’t know about you, but if the only way to get access to a really cool service was to go against basic security practices, then I’m happy to do without the service.

Here’s an idea. I’ve got this service which will monitor your bank account and send you a monthly report of where your money is going and (this is the really cool bit) will suggest places where you can save money by switching to other suppliers. It will even take any spare money at the end of the month and put it into the best investments it can find. you just need to give me your internet banking login details. Interested? I thought not.

And yes, Twitter are partly to blame for this. There’s a standard protocol for dealing with situations like this – it’s called OAuth. Twitter have been promising to support it for some time, but it’s still not here. And, to be honest, with the number of people who are quite happy to use their current, broken, authorisation model, why would they care about doing things the right way?

So here are a couple of suggestions. If you’re a Twitter user and you find a really useful Twitter-addon that you want to use but which asks for your password then don’t use it. And write to the owners explaining why you won’t use their service. And if you’re running a service which currently interacts with Twitter using passwords, then stop doing it. Close down your service. Explain to both your users and Twitter that you have closed your service until you can reimplement it safely.

I don’t expect for one second that all services will close down or that all users will stop using existing services. But it would be good if enough people stopped using the service until Twitter took notice and started using OAuth.

Who’s with me?

Update: A post from the Twitter development team on December 2nd promises “a beta of OAuth support [ … ] ready for our first deploy in the next week or ten days”


More Password Idiocy

When will web sites start to be careful with people’s passwords? Oh, I know that a few sites get it right, but it seems to me that the vast majority still don’t have a clue what they are doing. Here is today’s example.

I got an email this morning from a company called RAM (that’s Research and Analysis of Media). Somehow they knew that I was an (occasional) Observer reader and they were inviting me to join a panel that would (as I understand it) answer occasional surveys about the Observer. It sounded like a good cause, so I signed up. As part of that process I gave them both a username and a password. They immediately confirmed my sign-up by sending them both back to me in an email.

That is, of course, a serious cause for concern, but there’s a slim chance that they aren’t storing my password in an accessible form in their database. The mail might have been generated from the data in the web form I filled in. However, an hour or so later I got another mail from them telling my how to log into me account and including my username and password. In fact, that one email contained all of the information needed to log into my account (web site address, username and password). So they have established themselves as a company who can’t be trusted with your password.

On the off-chance that they wouldn’t be sending me any more mails containing those details, I thought I’d try to return at least a small amount of security to my account by changing my password. Except that there is apparently no way to change your password from within your account. By this stage they are breaking records for password stupidity.

I’ve contacted them about the problems and send them a link to my basic guide to password handling article. I’ll let you know if I get any response. I hope their surveys are constructed with a little more thought then their web site.

Update: I heard back from them about not being able to change my password. You can do that in an “update profile” screen. Not sure why I didn’t spot that last week. Nothing from them about the password storage issues though.