Banks: Stop relying on SMS based 2FA
Even in 2023, organisations continue to deploy new projects which rely on SMS messaging as their only multi-factor auth (MFA/2FA) option.
There was a time when deploying any form of MFA was something worthy of praise, but, modern deployments need to achieve a higher bar, and should offer multiple means of providing a second factor.
Planning, designing and deploying a project in 2023 which presents mandatory phone based multifactor authentication as the only option is something that (IMO) we really should start describing as little more than negligent.
The prompt for this post is that, unfortunately, I've recently had an email from Vanguard announcing their new MFA support which... is SMS only.
I've written previously, in some detail, why unnecessarily collecting phone numbers is an anti-pattern. Rather than regurgitating that, I want to take a quick look at the solutions that developers should be considering as well as talking, a little, about why SMS based authentication is particularly unsuitable for banking providers.
Phone based 2FA
First I just want to define what I mean when I talk about SMS based 2FA.
Obviously, primarily, I'm referring to a mechanism which sends you a code (often 6 digits) by text message. However, the same concerns extend to anything which relies on telephone connectivity: having a system which phones the user and reads a code is no less of a concern.
Banking is an unusual use-case
Let's start with the most controversial bit.
Internet banking is actually a slightly contradictory use-case: in that we expect high security but also accept that there must sometimes be some sharing of credentials.
UK law doesn't allow for joint ISAs or pensions, so a couple trying to save within these tax-free wrappers have to either put their savings under one person's name or maintain individual accounts. Obviously, the root cause isn't something that a bank can fix themselves.
Most customers, however, would reasonably expect that either partner should be able to quickly access the entirety of their shared savings.
In particular, if one partner were to be hit by a hypothetical bus, they'd generally want to know that their partner would be able to easily access those savings to cover anything from funeral costs to mortgage payments.
But, because there's no concept of a joint savings ISA, the only way to ensure this is to share internet banking login credentials. It's far from ideal, but works just fine as long as both partners adequately protect the credentials.
Although we normally think of credential sharing as tantamount to heresy, there's really nothing novel about couples doing this. Even 1Password's Digital Estate Planning Guide makes reference to the need to pass credentials on and the challenges that 2 Factor Auth poses in this scenario.
The problem is that the shared access model breaks once you add a mandatory second factor that is - by design - tied to something that only one partner will be in possession of: their phone.
With partner and phone having disappeared under a bus, that savings account, intended to ensure neither partner would ever go without, is rendered inaccessible until the surviving partner can obtain a death certificate (often weeks) and then navigate the complex headache that is UK probate law. They'll get access to the funds in the end, but not before extreme amounts of unnecessary stress are added to what's an already stressful time.
Unexpected death is obviously an extreme example, but it's not the only one.
Anecdotally, it's also not unusual for couples to have one partner manage the couples finances - whether simply because they've more of an interest, or because they're more apt at money management.
For example, one partner may be more interested in managing a private pension (or SIPP), logging in periodically to top-up contributions or check growth etc.
But with the addition of SMS 2FA, you're left with a quandry: which partner do you lock out of the account - the one who's name it is in, or the one who will be logging in most frequently?
Getting back to a less controversial usecase, the enforced addition of SMS 2FA can also impact individuals:
It's quite widely advised that people should try and maintain an easy access emergency fund to help ensure that their finances aren't destabilised by unexpected expenses.
With SMS 2FA, access to those funds is contingent on any emergency not impacting access to the relevant phone: As Terence Eden so aptly describes, that's really not something that can be relied upon. Any emergency involving damage to, or loss of the phone is suddenly potentially quite major.
SMS 2FA Security Shortcomings
I described the short-comings of SMS MFA in more depth in my earlier post, so I'll simply summarise them here.
- The codes are easily phishable
- It assumes mobile coverage, which isn't a given
- It relies on an unsecured communications channel, with those communications demonstrably being open to interception.
- It puts users at additional risk: At their worst, data leaks including phone numbers enable Doxing, SWATting and harassment campaigns. Examples of which have led to unnatural deaths.
- Data leaks including phone numbers also enable better phishing campaigns, especially when linked to account data (so much more effective, in fact, that personnel at high tech security companies have fallen for them)
- They are inaccessible to many users/customers - whether as the result of disability, poor phone coverage or simply having a dead battery
- Reliance on SMS 2FA as the sole mechanism is recommended against by NCSC and strongly advised against by the UK's Financial Conduct Authority
- Phone companies practice of phone number recycling leaves accounts open to hijacking
Alternatives
There was a time when the 2FA market was dominated by the likes of RSA, who sold banks overpriced one-time-code devices with an expiration date built in and everyone grumbled at having to carry a bulky "calculator" to authenticate with.
Things have changed dramatically since then and standardisation has led to a high level of peer review and device compatibility.
Many of the options available offer a much stronger level of authentication and security than SMS MFA ever will.
Time-based One Time Passwords (TOTP)
TOTP has been around for ages and doesn't require use of a potentially insecure communications channel at login time. The user just opens their app and provides the number that's been generated.
Adding TOTP support to a service is easy, because there are a huge range of opensource libraries designed to enable just that.
TOTP codes can be generated on a wide range of devices via apps such as Authy, Google Authenticator and Microsoft Authenticator. In fact, the user doesn't even need a phone because the codes can also be generated on a desktop.
TOTP codes are easy and convenient to use - more so, in fact, that SMS because they don't require that the user be within mobile network coverage.
However, like SMS based 2FA, TOTP codes are phishable: a fake login page just needs to prompt for the code and then forward it onto the real service.
FIDO2
The FIDO spec(s) use public key cryptography in order to provide strong authentication.
There are a wide range of FIDO2 compatible devices on the market, but often, all the user needs to do to authenticate is to press a touch sensor on their device.
The specification defines how devices communicate rather than the devices themselves, so there're a broad range of possibilities - ranging from hardware dongles (I love my yubikey) to apps. Although we tend to first think of (expensive) dongles like Yubikeys, they aren't actually necessary: any phone running Android 7+ can be used.
As with TOTP, there are a huge number of opensource integration libraries available making it easy to add FIDO2 support to projects written in almost any language.
Unlike SMS 2FA and TOTP, FIDO2 implementations are not phishable (although there are social engineering techniques that phishers can use to try and convince users to use a different mechanism).
Passkeys
Technically, I'm being disingenuous here, because Passkeys are part of FIDO2, but their potential means that they're worthy of their own section.
At time of writing, passkey support is still in the relatively early stages of being rolled out (so Vanguard can be forgiven for not including them), but looks extremely promising.
There's a demo at passkeys.io if you want to get a feel for the registration and login flows.
Password based authentication has always been problematic, whether it's users losing control or providers storing them unsafely, they're quite easily defeated. Increasingly, that's led to calls for passwords to be retired entirely and Passkeys have the potential to enable that security utopia (although, they should - IMO - remain optional in some settings).
Much like FIDO2 (ok... exactly like) they rely on public key cryptography to provide strong multi-directional authentication, with a huge range of device support - modern Android and Iphones support it out of the box!
Dedicated App
Some banking providers have historically opted to provide their own code-generation apps.
In terms of user experience, these aren't much different to TOTP - user opens the app and provides the generated code.
However, these apps are (IMO) inferior to TOTP:
- They require users to install a dedicated app, just for their bank
- They require that the user has a mobile phone
- Some rely on connectivity rather than using truly local generation - a drop in coverage means no access
- The underlying mechanism may not be as well reviewed - potentially leading to predictable values
- The security of Internet Banking apps, historically, has not overly impressed me
My biggest personal bugbear with these code generation apps though, is that they inevitably suffer from bloat.
Although I'd have preferred to use TOTP, I didn't overly begrudge installing HSBC's code generator app on my phone when it was first launched. It was a small, simple app which did one thing: generated authentication codes.
At some point though, someone decided to bundle it into a full-blown banking app instead, and withdrew the standalone app. So rather than simply generating 2FA codes, the app now provided access to my accounts from my phone, even though that's not something that I actually wanted.
Better than SMS 2FA, use of this kind of dedicated app is something I'd accept (but wouldn't advocate) as first choice. It's also the mechanism used by a lot of UK banks.
Shared Access
Earlier, I gave some examples of why shared access is sometimes needed to bank accounts.
Unlike SMS 2FA, sane implementations of each of the available alternative authentication mechanisms can be used to share access to an account.
Password managers such as 1Password support TOTP, allowing the necessary authentication to be made available to family members. Passkey support is coming too.
Although advisable, there needn't be any reliance on password managers either: sensible 2FA implementations allow users to register multiple FIDO2 devices to authenticate with (so that a backup authenticator can be added).
All much easier and more reliable, than hoping that nothing happens to a person's phone.
Meeting Banking and Business Requirements
Designing and implementing account security measures normally involves striking a balance between three factors
- Cost
- User Convenience
- Security
The most rigorous security measures are often the most inconvenient to users and can also be quite expensive for the provider to maintain.
As security measures go, SMS 2FA, is quite unusual in that it scores poorly on all three counts
- Cost: running costs include sending a SMS whenever a user tries to log in. Although an individual SMS is cheap, costs add up when scaled up to millions of users and other 2FA mechanisms don't incur this cost at all.
- Convenience: Reliance on mobile networks is not particularly convenient for those who do not have reliable coverage
- Security: the method is susceptible to interception and phishing. It's better than nothing, but inferior to the alternatives.
Putting it bluntly, SMS 2FA is an overly expensive implementation which only just manages to provide more than a false sense of security, whilst excluding a proportion of the customer base.
In fact, it's such a problematic method of authentication that in its guidance on strong customer authentication the UK's Financial Conduct Authority strongly directs against relying on it as a sole means of authentication
Whilst this relates to purchase time authentication, it seems reasonable to assume that the supervisory authority's concerns about accessibility would not only apply to the checkout process.
Similarly, the UK's National Cyber Security Centre recommends that alternatives be used
SMS is not the most secure type of MFA, but still offers
a huge advantage over not using any MFA. Any multi-factor
authentication is better than not having it at all.
However, if there are alternatives available that will
work for your use case, we recommend you use these
instead of SMS.
So, the question has to be asked: Why have Vanguard - a financial services provider - chosen to implement a second factor authentication scheme that provides inferior security, has higher running costs and is not in line with the advice issued by the UK's Authorities in both Cyber Security and Financial Services?
But, You trust them with your money
One of (many) problems with SMS MFA is that it necessarily means the provider needs to hold additional personal data: the user's phone number.
This data, almost inevitably, gets compromised. There's a fun set of examples of here. For users the result isn't necessarily just an increase in direct marketing, there are a number of other dangers too.
But, banks are different right? We trust them to hold onto whatever money we have, so why not our personal data?
The problem is, as convincing as this might sound, it's a mis-characterisation of reality.
We don't inherently trust banks not to screw up, and in fact we only "trust" banks to hold our money because it's insured - if the bank screws up, they repay. If the bank folds, our funds are replaced by the Financial Services Compensation Scheme.
In short, we let banks hold our money because we've been given strong guarantees that if that money is lost, it'll be replaced.
The same cannot be said for our personal data: once it's leaked, there's no bringing it back - the best that can be done is to try and mitigate the effects.
Now, there are other legitimate reasons for a bank to have a customer's phone number: the most common being to contact them if fraudulent activity is detected.
Arguably though, that's only really necessary for accounts that have a means of spending (i.e. a debit or credit card) linked to them.
If funds can only be withdrawn/spent by logging into the account, there's no benefit to having a contact number if that same number has also been treated as an authentication factor (because there's a good chance your fraud team are going to phone whoever logged in - true account holder or not).
Not to mention, of course, that those calls are much less likely to be necessary at all if better MFA methods are in use.
Conclusion
There simply isn't a good reason for any organisation to deploy SMS MFA as the only option.
It incurs unnecessary running costs whilst providing users/customers with less additional security that alternatives, all whilst potentially increasing the impact of a data leak.
Alternative methods of implementing multi-factor authentications are widely available, widely supported and simply do not have the usability and security short comings of SMS MFA.
That's not to say that SMS 2FA should not be used at all, but that it should never be the only (or even, the preferred) option.
In the case of financial services companies like Vanguard, such implementations are at odds with guidance provided by the industry's regulator, that provided by NCSC and are (as far as I can tell) out of step with the login flows used by the majority of the UK banking industry.
It's 2023, we have TOTP, FIDO2 and Passkeys - building around SMS 2FA and not including at least one of the others as an option is negligent.
