Categories
tech

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:

[snip]

  • 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.

 

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
tech

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.

Categories
tech

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.

Categories
tech

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.

Categories
tech

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.

Categories
tech

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.