Authentication in Financial Services: Improving on the Password
Financial Services are among the biggest targets when it comes to online security. Discover the critical user events that demand two-factor authentication protection and get tips on integrating the right type of 2FA into your services offerings.TransferWise's 2FA use case
Authentication in Financial Services: Improving on the Password
The financial services world has changed drastically from just a few years ago. In addition to local and regional banks, we now have blockchain-powered cryptocurrency sites, global money transfer operations, crowdfunding platforms, AI-based financial advisors, automated wealth management services, peer-to-peer lending and payment platforms, and other cutting-edge FinTech applications. It’s a crowded market, but one that has a common challenge of protecting customer accounts and their data. That’s where two-factor authentication, commonly referred to as 2FA, comes into play.
This article will familiarize you with several important aspects of account security for the finance industry: the critical user lifecycle events that demand your focus, various forms of account protection, post authentication tips, plus recommendations for moving your financial services company in the right direction.
Your customer opened an account. Now what?
Once an account owner is verified, a best practice is to confirm the user’s identity on each return visit. This allows you to protect their finances, private information, and personal settings at all times. At the most basic level, a username and password are required for account ownership identification. But these credentials, which have historically been user-generated, tend to be created so that they are simple to remember. This has resulted in “123456” consistently topping the list for most common passwords used. Because many username and password combinations can be can be easily guessed, stolen, or hacked, it makes total sense for financial institutions to require additional pieces of information, or factors, to be used for authentication of account ownership. These factors are typically grouped into the following:
- Knowledge: something the user knows, such as a PIN number, password, or numerical pattern
- Possession: something the user has, like an ATM card or a smartphone
- Inherence: something unique to the user, such as a fingerprint or an iris scan
Since the most common method of protecting accounts relies on a username and password, many users are at risk of account takeovers. Cybercriminals often use stolen passwords without the account owner’s knowledge. To make matters worse, people frequently use identical passwords across multiple accounts—from social networks to banking apps. This means that a data breach occurring at a less secure website could expose the password a customer uses in your application. Hackers can then purchase stolen or breached credentials and use them against other websites—and financial sites are usually the prime focus—until they find instances of reused credentials. This attack is called “password stuffing” or “credential stuffing” and is very difficult to detect or prevent because it doesn’t target a single account.
Passwords: not dead yet.
Before we get into how to improve user account security beyond just a password, we must accept the fact that the password, despite rumors to the contrary, isn’t going away just yet. While there are advances that will minimize our reliance on them, they are still a security tool we need to work with. To that end, there are steps you can take to improve the use of a password. Our advice is the following:
- It used to be best practice to enforce complex passwords from an extensive character set (a-Z, 0-1, !@#$%^&*). This made remembering passwords very difficult, although password managers have started to help with this problem. Current thinking is to advise users to choose passphrases, not passwords, i.e., string together a lot of words in a single password, such as “thisismyverylongandsecurepassword” and remove all requirements for the user to create one that is complex. However, it’s still important to catch passwords like “aaaaaaaaaaaaaaa” and common passwords.
- Password length should be at least 14 characters. Given the long passphrase trend, you should not apply arbitrary maximum lengths. If you must have a cut-off, we suggest making it at least 64 characters.
- Never base a password — even a temporary one — on any static data like a Social Security Number, name, or date of birth. This practice often happens when an account is created before the customer is aware and a password is sent to them via email.
- It goes without saying: never, ever email a password. No matter how temporary. Instead, for instances like a password reset, use an out-of-band verification system through a separate communication channel.
- Stop asking users to change their passwords every 180 days or so. Changing passwords don’t actually result in users choosing more secure passwords. Instead, you should only ask a user to change their password if you feel there has been an indication of it being compromised.
- Allow users to review their password before it is submitted. This will reduce any chances of a typo and/or a frustrated, locked-out user. Of course, default to hiding the password to avoid peeking eyes.
- Allow ‘copy & paste’ in password entry fields. Password managers are becoming more widespread, so let people ‘copy & paste’ their passwords. On mobile devices, consider using integrations with password managers like 1Password and LastPass to simplify getting the correct password into your app.
- More importantly, never store passwords in clear text. Instead, hash the password with a salt and use the latest recommended algorithm Argon2. (Although PBKDF2 and Bcrypt are also acceptable.)
2FA: Going beyond username & password pairs.
Let’s get back to the topic of improving on password security by looking at methods for authentication which don’t involve the username and a password. Biometric techniques are increasingly being explored, but issues of privacy have limited their widespread use. Additionally, biometrics currently have prohibitive hardware costs that have traditionally slowed down the adoption of this method authentication.
A more significant concern is that people don’t want their eye scans or fingerprints stored on servers where, if stolen, they can be reused forever. You can always reset a password, but it’s a bit harder to swap out your eyes. Another issue is that the service you provide biometric identifying factors to can essentially use them to impersonate a user in other services. For that reason, we feel that credentials which are not so strongly tied to an individual are likely to gain more traction in the long term.
Instead of replacing the password, application developers add another factor into the authentication phase. Ideally, this extra data is communicated over an entirely different channel to the one being used for the initial password. For example, a certificate may be issued to a smart card in the user’s possession. Optimally, this process will take place outside the channel of communication being used by the application the user logs in with, therefore avoiding man-in-the-middle attacks.
Adding a second factor creates a stronger method of authentication that is known as two-factor authentication (2FA), sometimes referred to as multi-factor authentication (MFA). After the password has been provided, a second factor is required to complete authentication. The most common method of 2FA, sending a one-time passcode via SMS, comes in handy if you are already asking for the user’s phone number. Other factors include various physical security devices, like a FIDO U2F security key, but they have downsides. Physical devices like these often incur extra cost, typically at the customer’s expense and are prone to be lost, or left at home. This is why SMS-based 2FA, and the mobile device it is received on, are such popular second factors: they’re typically always with the user. And if lost, the phone number can be moved to a new device/SIM for continued account access. An improvement over the convenience of SMS is the more secure authentication available via a mobile or desktop app. But the most convenient 2FA (and the most reliable) is initiated by a push notification that allows account owners to be authenticated with a single touch.
When looking at authentication, we often forget about the subject of authorization. Regardless of whether you’re focused on cryptocurrency, credit services, peer-to-peer payments, or traditional banking services, keep in mind that even authenticated customers are at risk. Clever and complex social engineering methods are being widely used by attackers to take over user desktops and spy on authenticated browser sessions. Therefore, when thinking about 2FA, keep in mind that some authentication methods explored in this article are also very applicable to authorizing transactions within an application. For example, 2FA protected authorizations are very popular with cryptocurrency exchanges which need to secure the transfer of digital currencies out of their online wallets.
Before we dig into each 2FA method listed below, note that they can all be implemented alone, or in conjunction with another. And while each has pros and cons, all forms of two-factor authentication significantly increase the security of your users by protecting their accounts — and your brand reputation — in the process. In essence, any 2FA is better than usernames and passwords alone. Let’s explore each in more detail, after which we’ll advise on how to use them all.
SMS, the easy way to 2FA
2FA is most commonly implemented via SMS because SMS is universally simple. There's no learning curve (everyone knows how to read a text), and users don't need to install an app to receive a 2FA code. Plus, any GSM or CDMA phone can receive a text. That’s important in regions where smartphone penetration is still low, especially when considering that by 2019 feature phones will still outrank smartphone usage by nearly 2-to-1.
After entering a username and password (or initiating a transaction that needs authorization), the user receives a unique one-time passcode (OTP) via text message, which then must be typed into the app before access is permitted (or before the transaction completes). For low-risk online activity, like video streaming sites or hobby forums, SMS-based 2FA often fits the bill. But for financial services accounts, a higher level of security is recommended to protect sensitive personal information and real financial assets.
Voice call for complete coverage
Voice-based 2FA is a common backup to SMS for non-mobile phone authentication. While SMS delivery rates vary over the globe, voice is prioritized on carrier networks and gives the greatest reliability. For regions where mobile phones are expensive, or where cell service is poor, voice calls to landlines offer complete coverage, and software-based text-to-speech services allow for the support of dozens of localized languages.
2FA via SMS and voice also requires the same set of features as when SMS is used for phone verification. When 2FA is enabled on an account, check if the phone number supports SMS. If not, default to using voice. It’s also essential to ensure that 2FA messages are translated to the local language of the user’s region. This is true for any 2FA communications whether it be a written message delivered via SMS or one that is spoken via a voice call. The country code is the easiest way to determine region and TTS services can help reduce the cost of having translators record audio files.
Why are SMS and voice-based 2FA considered insecure?
Undeniably, SMS and voice-based 2FA are better than relying on just a password. But there are a number of vulnerabilities we've seen in the wild that degrade the security of the channel by allowing bad actors to intercept the security codes being sent. At one point NIST recommended that 2FA via SMS or voice be deprecated. However, they have since reverted their stand on this.
The problem is twofold. One aspect lies in the fact that the network which all mobile phones connect to (called the SS7 network), and the telecommunications companies that run these networks, have differing security practices. The other aspect is that unlike secure internet-based messaging communications, like Apple’s iMessage or Facebook Messenger, SMS messages are often sent across the networks in clear text (although the last leg from the base station to the phone is usually encrypted). This combination has led to instances where criminal organizations gain access to a regional segment of the SS7 network and can redirect 2FA codes to their own devices. Other attacks on phone numbers involve hackers tricking a carrier into transferring the phone number to a new SIM, and therefore giving the criminal access to the users SMS and voice calls.
There are even examples where some carriers allow their customers to login to a website and view SMS messages in the browser. If the websites are protected with only a password, and the hacker knows it, it takes minimal effort for them to access the 2FA codes by simply logging into the carrier website.
Like SMS, voice-based 2FA is also vulnerable to exploitation and the same SS7 attacks. One way to circumvent vulnerabilities is to challenge users to enter a specified keypad pattern before delivering the passcode verbally. This ensures the recipient is a live user and not a computer bot intercepting and automating the capture of the passcode.
Again, while these issues are serious to consider, it’s important to keep reminding yourself that 2FA via SMS and voice calls are still a big improvement over passwords alone. Many of the issues we're describing are very difficult to perform and can often require a significant investment of time and money just to target a single account. But when that account contains millions of dollars, the rewards are worth the effort. Again, risk is specific to the user. For low-risk activities, such as posting to a comic book forum, 2FA via SMS is probably adequate. But a financial account of significant value should absolutely not be protected by SMS or voice.
TOTP-based 2FA for those without connectivity
For smartphone users who can download apps, a ‘soft-token’ solution is a more secure choice. A preferred alternative to SMS and voice, this software-generated, time-based one-time passcode (TOTP) works anywhere, even when the device is offline.
Soft-token TOTP apps work similarly to 2FA provided through hardware tokens: a small device that displays a randomly changing number and is typically carried on a user’s keychain. However, as mentioned previously, hardware tokens are costly, easy to misplace, and require a customer to have a separate device per each protected service. Soft-token apps are free to download (meaning no associated distribution cost), can manage tens of 2FA accounts for multiple services, and are conveniently within reach since we're rarely far from our smartphones.
Using a soft-token app is easy. And the process is almost identical to using SMS and voice. At login, when the 2FA step appears after the password entry is accepted, the user is asked for the 2FA code. Instead of receiving this code from the service via SMS or a voice call, the user is prompted to open the app on their phone, tablet or desktop. Because the code is generated and displayed on the device, soft-tokens aren't vulnerable to interception (assuming you are using HTTPS). However, they are still susceptible to phishing attacks where users can be fooled into typing their real TOTP code into a false or malicious website, which then enters the data against the legitimate application.
There are two main ways to get the TOTP code on the user’s device: either direct them to download a free third-party authenticator app or embed the TOTP functionality directly into your own mobile application. Authy, Google Authenticator, and Microsoft Authenticator are just some examples of free 2FA apps available. The better apps come with many compelling features, such as multi-device options that provide users the flexibility of getting 2FA codes from their mobile device, a laptop or desktop version, or from wearables like the Apple Watch. Since it’s inevitable that users will lose access to their device at some point, backup options are advisable. Not every downloadable 2FA app is the same, so compare.
If your business already has a mobile application, and you have access to mobile developers with security skills, you might decide to embed the TOTP functionality directly into your existing app. The advantage here is that you have a lot more control over, and can brand, the 2FA experience, further increasing user confidence that they are using a trusted service. It also reduces the need for your users to download another app.
Of course, users are tricky beasts. While you would think they would delight at the opportunity not to have to download yet another app, some will want to enable 2FA using the free authenticator app they've already installed and configured. To accommodate, you may end up implementing multiple TOTP options. If that's the case, it would be wise to look for a 2FA API that you can embed into your application which provides an authenticator app as well as an SDK (and also likely supporting SMS and voice) to reduce your implementation efforts considerably.
Push authentication for modern protection
Authentication via a one-time passcode is nothing new. The practice has been around for over 30 years and is still very popular due to the extensive use of SMS enabled devices. That doesn't mean there isn't a better solution, one that significantly improves security yet also presents a much better user experience. As overused as the term is, push authentication truly is "win-win."
Push authentications start with a mobile app: either as part of one of the free authenticators already mentioned or embedded into your existing mobile and desktop apps. When the customer completes the username and password step, a push notification is sent to the devices they've already installed and authenticated. This notification, typically containing images to reinforce that it's from a trusted source (i.e., your company logo), prompts the user with context and clearly communicates the request to approve a login, authorize a money transfer, or permit another action. Notifications include details confirming where the request is coming from (i.e., an IP address), the device type on which the action is taking place (i.e., your Mac OS laptop), the account being accessed, and other details specific to the activity.
The most important aspect of this type of authentication is how the user responds: either "approving" or "denying" the request. For someone who is legitimately in front of their computer accessing their online bank account, they'll simply touch "approve" to be instantly logged in — a far more streamlined user experience than having to receive, read, and enter a one-time passcode.
The critical difference here is the ability to "deny" a request. Imagine sitting in a coffee shop, receiving a text message that reads “Here is your 2FA login code: 123456” even though you’re not doing anything that would prompt a 2FA code. What do you do next? What support email or phone number do you contact? How do you know any details about this request? Usually, by the time you’ve figured out who to call, the attacker has already done damage to your account.
With push authentication, the account owner merely taps "deny" with full confidence that they’ve just stopped an illegitimate action. If a user taps "deny" multiple times in succession, the developer could interpret that signal as something is wrong and can take appropriate actions to further protect the account.
Push authentication can also be used to get a step closer to removing the password entirely. Google and Yahoo have both implemented push authentication features that allow a user to provide only a username at login, with the second action being a response to a push authentication on their device. This doesn’t always mean there is no password on the account, just that it’s not being used at every single login, further reducing the chances of a stolen password being used to authenticate on to a website and take over an account. Instead, the password is used only for setting up new devices or browsers and typically would involve push authentications along with the use of the password.
One thing to consider is that push authentication only works with an internet-connected device that can install apps. In areas where smartphone penetration is low, or where the internet is unreliable, OTP or TOTP authentication can serve as a fall-back. But where it is an option, push 2FA is recommended as a more user-friendly, and more secure, authentication channel.
Take 2FA a step further: decisions after authentication
There’s just one more area to discuss before we get to the recommendations. Even after the user has completed a valid 2FA step, the act itself might provide you with some data that can further improve your final decision to authenticate or not. Risk-averse businesses, especially online banks and digital currency platforms, are keen to know as much as possible about where 2FA codes come from and how much they can trust the device used to authenticate.
Passwords—and the user's phone number—are typically static and don’t often change. But there are other factors, or to be more accurate, signals that you need to include in your decision to authenticate a login or authorize a money transfer. These are things like an IP address, GPS coordinates, and device type. By combining a set of known credentials with appropriate signals, authentication becomes more than just a binary “did the user give me the right password?” or “did they give me the 2FA code I just sent via SMS.” Signals allow you to contextualize the decision of whether or not the action a user wants to perform fits the risk.
Both TOTP-based 2FA and push authentication run in software, on a user’s device, and can go beyond just checking if a 2FA code is valid. Useful information might include how and when was the 2FA app was installed, the frequency of use, whether it’s running on a desktop or mobile device, and whether the user has explicitly declared trust in this device. Looking up data on a phone number can also give useful information about whether or not the phone is roaming or has recently been ported. These methods can provide real-time data to help financial services make better authentication decisions. With those data points in mind, consider these potential use cases:
- Look up data on the phone number, and if it’s marked as roaming, or has been ported in the last 24 hours, you might want to prohibit SMS-based 2FA. These signals can indicate a successful attack on the user’s phone number.
- Assess risk based on location by comparing IP address and region of the initial account registration with those of the current 2FA request.
- Disallow 2FA codes generated from an app on the desktop, when the user is accessing your website from a browser on the same desktop. This also applies to only allowing desktop-generated codes for securing mobile applications. The point here is, don’t accept a soft-token generated on the same device the user is accessing their account.
- Immediately validate a 2FA code (and remember the device ID) at the time of enablement. Require that same device for future authentications.
- If another authenticator app has been installed on a new device, apply a 48-hour waiting period to notify the account owner before trusting the newly installed app.
The key here is contextualizing the authentication step by using as much information as possible at the time of login or transaction. Even if a user successfully types in the OTP code, or has responded “approve” to a push authentication, think about the other signals that can be used to judge the risk of allowing the action to continue.
So which type of 2FA do you choose from this bewildering list of options? Unfortunately, there is no silver bullet. You could select just one, the most secure, and force users to use it. But this lack of balance between usability and security will prevent some users from being able to enable it.
How do you offer all these options? In what order? Our advice to you is:
- Do your research. Companies like Google, Microsoft, Facebook have large engineering teams dedicated to trying to make their authentication flows work well. They are never perfect, but by taking the time to learn how they work, you’ll benefit from their experience. These big technology companies also set the standard for how to authenticate, and as such, your customers will be familiar with certain language and methods of authenticating. The more you can mirror these methods and use similar language, the more likely your customers will seamlessly authenticate with your business.
- Support as many methods as possible but start with the most secure as the default, which is currently push authentication. Degrade gracefully, offering the next most secure option and be clear about the benefits of the decision the user will make.
- Include as much information as possible at the time of authentication to inform the user. For example, when using push authentication, you could include a map of where the authentication request is coming from. Use company branding (names, images) to reinforce that the 2FA request is legitimate. The more the authentication looks legitimate, the more the user will have confidence in their safety while using your services.
- Use as many signals as possible to contextualize and further secure the authentication. For example, when accepting a TOTP code generated from a smartphone, can you get information on the device used? Was it a device you’ve seen before for authentication? Did the device have an IP address that’s in the same geographic location as the browser or app with the authentication request?
Financial Services: Solving for multiple security needs
Bringing financial services online offers considerable benefits to consumers, but it also comes with huge risks. And those risks are rapidly changing and growing. Regulation, however, is catching up and starting to force stronger authentication and customer verification techniques along with deadlines that, if missed, incur fines.
Sign-up, authentication, and recovery are the three most important areas in which you can quickly elevate the protection of your customers. As described in this article, there are many quick tactics you can implement. However, due to the ongoing costs and constant evolution of threats to customer accounts, many companies today are creating dedicated account security teams, a combination of engineering skills and security/fraud professionals whose jobs are to evaluate risk and implement solutions.
None of this can be afforded, though, if you don’t understand the cost impact on your financial services business. Being able to analyze loss of revenue and find a way to measure improvements stemming from new account security programs is essential to the long-term strategic plans to protect your customers.
As you become more familiar with two-factor authentication, you’ll discover new events in the customer journey at which you'll want to authenticate a user. Whether it’s authorizing new logins, approving password and account changes, protecting high-risk events, confirming valuable transactions, or recovering accounts that users have lost access to, Twilio Account Security solutions allow you to keep your users safe while simultaneously reducing the possibility of fraudulent activities.
The Twilio Authy API, combined with our free Authy 2FA app, offers security that goes beyond standard password protection. Some clients opt for the Authy SDK to embed 2FA directly into existing apps. Twilio provides both with easy enrollment, edge case coverage, and 24/7 user support. Plus, regular upgrades make our security solutions uniquely sticky. Your users will not only appreciate the extra level of security offered; they'll have fewer reasons to take their financial business elsewhere.