Musings on bank security: part 1, authentication for account access

A couple of months ago I promised a post on bank security. The topic is not an easy one to write about, as I would not say I have the chops to talk about it. After all I have never worked at a bank, and unlike Andrea I have not spent years researching into payment processing security.

I am, though, confident enough to write about some of the user side security implementations (and blunders) of banks, for the simple fact that I have had more interaction, than the average person, with multiple banks in different countries. I can thus compare notes about these different banks and countries, so I can point out what is good and what is mental in their implementations, as I see it.

If you are looking for more in-depth security analysis, such as Point-of-Sale security or Chip-and-PIN analysis, I would suggest you look up talks of people like Andrea Barisani, linked earlier, or Krebs on Security — who should probably write an ATM skimmer guide, companion to Spam Nation. Both of them spent real time digging into the inner working of banks, which I haven’t done.

In my discussion of security features, I’ll be accepting as valid the research on security questions, published earlier this year by Google. Not only I find the results pretty consistent with my personal experience (even though this could be counted as confirmation bias), but once again because I accept the results and information coming from people who have had more time, and more data, to think about the problem.

The objective of this blog is to discuss which security features are in use by banks to protect customers, and whether these features work towards or against that goal, but before I dig into the nitty gritty details, I think it’s important to define what these security features are meant to protect in the first place. It might sound obvious, but talking about this with different people showed it not to be the case.

The obvious part is that you don’t want a random attacker to gain access to your bank account and transfer your money to their account. This is the very minimal protection you expect from your bank. You also don’t want people to know how much money you have, or where you spend it — leaving aside the favourite talking points of privacy advocates on the matter, knowing this kind of information is a treasure trove for blackmail.

There are many more pieces of information that should stay private, and often are not. Most people (but of course, not everybody) know to keep the number of their credit/debit card safe. What is not that obvious is that your IBAN (and BIC) should be kept secret, too — for my readers in the United States, these vaguely correspond to account numbers and ABA. People are used to see IBANs for various companies and utilities displayed on websites or invoices, explicitly so you can make payments to them, but that does not mean personal accounts should be advertised the same way. Jeremy Clarkson fell for it, too: he assumed that having someone’s IBAN, Sort Code – which is actually already part of IBAN, but let’s move on – and registered address would at most let people sending money to him.

What he found out is that, in addition to sending money to him, someone could set up a direct debit against his account. In this case, the “prankster” decided to set up a £500 direct debit, if my memory does not betray me, towards Diabetes UK. And he probably didn’t even notice that until he went to check his statement. On the other hand, if you think of doing the same to a person on a regular income, you can easily cause them trouble. This is a kind of attack I like to call Denial-of-Cash: it is a similar attack to a Denial-of-Service — it does not gain the attacker anything directly, but it’s a common tactic to set up blackmailing, or just to cause (big) inconvenience to a target. Protecting against Denial-of-Cash is in my opinion just as important as protecting against blatant theft.

As I’ll show later, most banks have proper protection in place against theft, but Denial-of-Cash is a different story. Usually there is tight security against transferring money to a new account, but transfers to a known account require minimal or no security. An attacker may not be able to take the money from the victim, but they may still be able to remove economic means from the the victim, at least for a while — I say this because I’d expect most of the frequent payees would allow you to get your money back at some point, even if they are utility companies rather than family members.

You could think that nobody would have time to waste in this kind of attacks, since it still require going after access to a bank account. But then I would point out that the Internet is full of people spending time, and money, to achieve what is at best nuisance and at worst terror: (D)DoS, SWATing and doxxing. Given how much time people have to spend going after public figures they don’t like, this kind of attack is far from unlikely.

Now, before I start talking about the actual security features, I should provide the list of banks I’m going to talk about. These are going to be split across four different countries: Italy, USA, Ireland and (in a very small way) UK — these being the countries I spent considerable amount of time living in, or having contact with.

My longest-serving bank is my Italian one, as I’ve been a customer of UniCredit Banca for well over ten years; you may know this bank from some of their branches in other european countries, including many in the former Eastern block. I doubt it shares infrastructure or security features between these branches though.

In Ireland, where I currently live, I have tried three different banks: AIB, KBC Ireland – a Belgian bank, although I’m not sure if it shares anything with their main branch – and Ulster Bank. The latter is part of RBS Group, and so is my only UK bank – Ulster Bank, Northern Ireland – and I know for sure they do share lots, if not all, the systems between them.

To complete the picture, in the United States I have and use a Chase account. I also used to have the City National Bank account, a smaller Californian bank, from when I lived in Los Angeles, but I have no idea what their systems look like at all now, so I’d rather not talk about them.

In addition to the banks themselves, I can provide some comparison with other financial services: Charles Schwab (a stock broker), Transferwise (a service that allows you to transfer money across currencies at acceptable rates and fees) and PayPal. I should probably count Tesco Ireland as well, since they are my credit card provider, but I’ll just add a note later about that.

Also, before I continue, I would point out that this is already making me uneasy. My paranoia would push me to hide where my money actually is. I will continue, though, under the assumption that anything that happens would be proving my point, and I hope I have enough redundancies, so that a Denial-of-Cash attack would not really be feasible. I will also point out that my birthdate is not strictly a secret, also my mother’s maiden name is not very well known and that’s going to stay that way — it is obvious to the people who know me in person from Italy, but other than that there is no online connection between me and my mother. This should appear obviously relevant pretty soon.

Let’s start with accessing the websites of the banks — all the six banks have an online banking system: this is actually a requirement for me, especially as I’m traveling for a good part of the year, and not even live in the country the bank is in for most of them. With the exception of Chase, the other banks provided me a numeric-only user ID.

For both KBC and Ulster Bank, the user ID was formed by my birthdate followed by four allegedly random digits; but in the particular case of Ulster Bank, you can lie on your date of birth at registration time, as I found out by making a mistake.

Chase is the only bank that let me chose my own username — they insisted in a alphanumeric one, so it’s not my usual one either. Transferwise and PayPal, as they are essentially “born on the Internet”, use email addresses as identifiers, which I like, since it’s one fewer parameter to commit to memory, but is obviously not secret. Charles Schwab generates usernames based on names.

The situation with passwords is more interesting. The Internet companies are the ones that act the most natural by allowing a single password, with all kind of characters and a fairly high length limit. Chase is the second most sane by allowing me to select my password, although it is case-insensitive – and I’m not sure if they use a hashing that normalizes the case, do a case normalization on the client side, or if they store passwords unencrypted, I hope for one of the first two.

Ulster Bank comes third by allowing me to choose both my password (long, alphanumeric, case sensitive) and a numeric-only PIN, but then they mess it up by doing something crazy. Then it’s followed by Charles Schwab (8-characters alphanumeric password), UniCredit (8-digits numeric-only PIN) and AIB (5-digits numeric-only PIN, and the same craziness as Ulster Bank). KBC is not in the list by not having a password and doing something slightly more insane, which I’ll get to later.

What Ulster Bank and AIB both do, which I find crazy, is asking you to provide them with only parts of your password and/or PIN. For example, they may ask you the 1st, the 6th and the 13th characters of the password — in the case of Ulster Bank they ask three out of four digits of your PIN, and three out of at most 20 characters of your password, together, to log into their Anytime Banking website.

This is not a completely mindless choice: it finds its reasoning in dealing with phishing attacks — if you know your bank will never ask you for the full password, the attacker can only hope to get parts of it, and it’s then unlikely they’ll be able to enter your online banking, as they’d have to be asked exactly those characters they just phished out of you.

Unfortunately this improves security only in theory. In practice it makes it worse. The first problem is that lots of people will not consider “my bank will never ask me the full password” as an absolute truth, and because of that, phishers can still just ask for the full password and be done with it. The second problem is that it requires people to come up with passwords that are not only memorable (and those are bad passwords), but also easy to count into, for example by joining together very short words, or other similar mnemonic tricks. The third problem, which honestly bothers me the most, is that this stops me from using a password manager like LastPass to auto-fill the password for me. See also this Wired article that was published while this blog post was still in draft.

As for the phishing this technique is supposed to prevent, I’m sceptical. The base idea is that a phishing attempt would only easily get three characters from the password by phishing the form, and thus it would require an incredible luck for them to be asked exactly those three characters. I can find multiple ways to invalidate this precondition, take for example the 5-digits PIN of AIB, the phishers only have to tell the user that they were mistaken in one of the digits and then ask for new challenge, asking the two missing ones.

But even more importantly, there are more sophisticated phishing attempts — say that you are going through a malevolent VPN or proxy, the attacker can implement a pass-through to your bank and still let you access all its functions — I’ve seen the proof of concept for similar sites, and heard colleagues in IT security talking about similar phishing attempts. In this case the attacker only needs to make sure to not close your session when you’re done, and just before the session gets interrupted by your bank, take control of it. Most people wouldn’t notice the added latency, and not everybody figures out something is wrong if the full name of the bank is missing on the location bar.

These requirements thus do nearly nothing to stop cybercriminals, but they weaken both the password quality and the password management, the worst of both worlds. My suggestion, based on both experience and the research brought by other groups and experts, is to allow people to set their passwords, at least alphanumeric ones (allowing symbols is good, requiring them not so much), and stop using PINs — phishing will happen anyway, make it harder for criminals to gain access to accounts by guessing numeric 6- or 8-digits passwords, which end up most likely as dates, either date of birth of the owner, or friends and family, or simply important dates in their life.

When I started this discussion I explicitly left KBC alone; the reason for this is that they don’t use passwords, and instead rely on their mobile application for authentication — and this is going to be the next topic of discussion for all the banks. To login on the KBC online banking from your computer you need first to have the mobile app configured, and log into that one. Then you can use their one-time PIN generator to use for login, together with the user ID that the bank gave you.

It may sound at first like a good idea, but it requires you to not lose access to your mobile phone, if you want to access your bank for any reason. The easy case if your phone crashes, or breaks, and you have to reset/replace it, in which case you just need to get another SMS on the registered phone to set up a new copy of the application (but it does not help if you’re traveling and the phone number is not actually available.) Worse, if you get your phone stolen, you now will have to first wait for a new SIM to take control of the phone number before you can gain access to your bank account.

At this point I think it makes sense to point out that there are two “schools” in dealing with mobile banking applications: AIB, Ulster Bank, and Chase allow you to install many copies of the app on different devices, so you can always have one at hand set up to access your account. On the other hand, KBC and UniCredit only allow you to set up the application on one device, and if you need to install it on a different one you have to deauthorize the one already installed.

The best, in my opinion, mobile app is the one from Chase: you simply install it and then login with the same credentials as the online banking website. It’ll ask you the password every time, but it does work fine with LastPass, and you can switch accounts as needed, which I find great.

All the other banks require setting up the application for one account only. I hope this is because they generate client-side secure credentials, but I’m too scared to actually try to figure out what the apps are doing. But nonetheless, it means that to set up the application you need access to the registered phone number. Luckily, none of them require to read the SMS out of the device store, which means you can use them on phone-like devices that can’t receive SMS, or even on a device that is not configured for the given phone number.

This becomes important when you have bank accounts spanning different countries (four in my case, but only three need a local phone number); to solve this problem, I ended up buying a Nokia 130 featurephone which is dual-SIM, and allows me access to my 3 UK and Wind Italy phone numbers — if I had kept my number on 3 Italy I would have had a three-of-a-kind! This by the way works out fine unless I’m physically in the UK, as then the 3 UK can’t connect, as the phone is not 3G.

If the user is tied to the device, for most bank, what password you use with it is quite different. As I said, Chase lets you login with the same credentials as the online banking, which makes it the most sane solution. AIB also follows the same setting as the website, and it allows you to login with the same three out of five digits of the PIN. UniCredit, while forcing you to register your account number with the application at setup time, it also uses the same PIN you use on the website (with no support for LastPass filling the form, but at least allowing to paste the password copied from it.)

Ulster Bank and KBC instead ignore your online banking password (or precisely in the case of KBC it does not have one to begin with), and instead ask you quite explicitly for a PIN (digits only) that is tied to the device itself. I would hope that this is actually use to encrypt the client side certificate, but I’m not sure i I want to verify my hopes.

The problem with mobile PINs is, once again, that it’s one more separate piece of authentication to remember. And with the exception of Chase and UniCredit, as I pointed out, none of them allow you to use LastPass to store the involved PIN. The end result is that people either re-use another set of numbers, like their birthdate, or someone else’s, or even re-use the PIN of the device if there is one at all — and since figuring out the PIN based of oily pattern on the screen is far from impossible, you just have given up access to your bank account details.

Let me make something clear here: if you think that the people around you are all your friends, then you’re mistaken. I would love to live in the world you’re thinking of but I don’t. There are bastards around you just as much as there are great people, and the people you list as “friends” on Facebook are often not. Not only my birthday is not a secret, nor should my sister’s or my mother’s or whatever else. Facebook makes it easy to declare important dates for you — if something is an important date never use it as your PIN! I guess I could write a post about the dangers of 8-digits PINs.

I think this is going to be already quite the post, so I’ll follow up with the rest of my musings on bank security in a separate post.