Building Your Gold Standard For Account Access

In this article we are going to look at the key use cases you should consider around protecting access to your users’ accounts and what you should think about when building your gold standard security to protect them.

The financial services industry is often quoted as the most advanced sector when it comes to security, but the recent discovery of a large scale account takeover operation by IBM researchers suggests that even current best practices can be circumvented by well resourced and well organized criminal groups, and that the mobile channel is particularly at risk.

What Did The IBM Researchers Find?

The research team established that a large cluster of mobile emulators was being used to target major financial institutions in the US and Europe, and that they had already successfully extracted millions of dollars through short bursts of well planned attacks against identified accounts and banks.

It appears that the criminals had access to basic account credentials, presumably extracted through earlier phishing attacks or bought on the dark web. Having valid user credentials is of course not enough to access a bank account so the group set up a large network of mobile emulators so that they could spoof mobile device characteristics. Most financial operators require users to register their mobile devices with their service and when they do that, certain characteristics of the physical device are extracted and retained for verification on future logins, so this was a key component of what the attackers needed to do.

Moreover they had set up mechanisms that allowed them to intercept API traffic between the mobile emulator and the financial institutions. This allowed them to test and verify that their exploits would work and also to monitor ongoing attacks and react if their activities were detected.

Finally, they were able to intercept SMS messages which are often used to confirm login or transaction details. All in all, this criminal gang had most of the bases covered. From our own experiences of protecting against fraud and other attacks through the mobile channel, the setup described by the IBM researchers is not unusual.

Account Access Use Cases

Before looking at how you can prevent unwanted access to accounts on your platform, let’s consider all the different flows where users sign up or sign in to accounts, and the various points in the process where they get validated or re-validated:

• New account onboarding. This is often considered the most difficult use case, for good reasons. After all, when a new customer signs up, you have limited information about that user that you can use to validate that they are who they say they are. Some countries have digital ID cards which certainly help and the Nordic countries have even gone a step further in setting up BankID which is administered by the banks and operates across the region. Obviously it is a requirement of any good onboarding flow to request data which can be independently and digitally verified, such as digital IDs where available. The most important thing to note here is that the onboarding flow is particularly vulnerable to automation because of the limited information needed to invoke it.
  
  
• Existing account login. This is the use case that is usually considered in detail since it is used most frequently. Once you have a validated user with a registered mobile device using your service then you have multiple touchpoints that you can verify, and most service providers use a multi-factor authentication (sometimes known as two-factor authentication or 2FA) approach to enable login. In addition to checking usernames and passwords, they will most likely verify other independent data points such device characteristics, biometric properties or one-time codes sent by SMS. 
  
  
• Post login transactions. This use case sometimes gets forgotten about, except for unusual transactions. The thinking here is that once you have gone through the rigorous login process then a ring of authenticity has been created and there is a limited set of things that can go wrong. As we will discuss later, there may be some false logic here which should be considered.
  
  
• Password reset. This is an important step to protect well and it is necessary to validate the user with multiple factors. Relying on some subset of the data which is normally used during a regular login can help here. If you have device characteristics or you have implemented biometric authentication, you may be able to consider these as independent factors to validate.
  
  
• New device registration. Since you probably use characteristics of the mobile device to validate the individual using the app to transact on your platform, having to re-validate on a new mobile device creates some additional risk. In these situations you need yet another factor such as biometrics or a special passphrase to provide the comfort needed to enable registration of a new mobile device. 

All of the above use cases should be reviewed in detail and the risks and consequences of each thought through carefully.

Your Security Options

Security mechanisms can become very annoying to genuine users so there is always a fine line to draw between showing users that you take security seriously and making it a barrier to a good experience of using your app. Let’s examine the strengths and weaknesses of some commonly deployed security mechanisms around account access: 

• User Authentication. There are many flavours of user authentication, ranging from simple username and password verification to software and cloud based services which perform the user authentication and provide a token as proof of authenticity. Most of these services implement a flavor of the OAuth2 authorization framework or the OpenID Connect authentication layer which sits on top of OAuth2. Regardless of the protocol followed, these processes result in the production of a token which is presented to the backend system to gain access to the relevant account. These tokens may have a lifetime of hours or days and that is a long time in attackers’ terms so if intercepted the tokens are very usable. Therefore user authentication should be considered as a baseline and not a complete security solution for account access.
   
• Two-Factor Authentication (2FA). As described earlier, second factors such as mobile device characteristics and one time passcodes delivered by SMS can be deployed as an extra independent check on top of user authentication. However, as illustrated in the IBM researchers’ work, device information can be easily spoofed and SMS interception can be achieved, nullifying the impact of these second factor checks. For platforms which are used by citizens covered by privacy regulations such as GDPR in the EU, you also need to be careful that the device characteristics you are gathering are not considered to be PII (Personally Identifiable Information). For SMS, user installation of seemingless harmless apps which have SMS access permissions and nefarious code embedded in them is a common exploit.
  
  
• Biometrics. This approach has become very fashionable in recent years, particularly in the financial sector. There is no doubt that there is very strong technology at play here in recognizing unique properties of the human face or hand and to be able to differentiate between the presence of the real human as opposed to a video or image form. However, the weakness of these approaches in the overall account access process is firstly that in the end they will produce some kind of token or identifier which has a lifetime of interest to attackers and might be intercepted; secondly that it is a once-in-time validation and it doesn’t say anything about what might happen to the account session after the login. In this latter regard, it is of course similarly at risk to circumvention as user authentication and 2FA.
  
  
• Man-in-the-Middle detection. It is very important to know when the API traffic between your mobile app and backend servers is being watched, intercepted or modified. This is particularly relevant post-login when late attach mechanisms can insert themselves into the traffic to take over or influence ongoing account access sessions. Certificate pinning is good practice when securing API channels because it makes traffic interdiction more difficult but for attackers with the right experience and toolset, bypassing pinning can unfortunately be shown to be relatively straightforward. 
  
  
• App Authentication. This approach enables you to be certain that incoming requests are coming from a genuine mobile app instance running in a safe environment. Regardless of the account access use case you want to protect, this can be a very useful additional factor to add to your checks. Authenticating the app means that scripted traffic can be detected, even if valid credentials are presented. App authentication will also prevent attacks emanating from app clones which your users have been tricked into downloading, or genuine apps operating in runtime environments which you consider to be unsafe. 

All of the above approaches should be reviewed in detail and the risks and consequences of deploying them considered carefully in the context of your account access use cases.

Building Your Gold Standard

Account access via the mobile channel is the hardest to secure because you don’t control who downloads your app and how much time they spend preparing to attack you by reverse engineering your app and studying how your API operates. 

It’s vital that you consider each of the five use cases outlined above and decide what variety of independent factors, e.g. user, device, biometrics, SMS, app, etc. you will verify in order to grant account access in each case. As a useful guide, review the cyber criminal setup revealed by the IBM researchers and check that whatever account access factors you decide to use to protect your platform would enable you to detect unauthorized account access by this class of attacker. If not, you are not doing enough.

Also, please don’t assume that attackers will not target your business; they will - it’s just a question of time and of how difficult you make it.

In Summary

It should be clear by now that the criminal group responsible for the activities detected by IBM had managed to bypass user authentication, device authentication and two-factor authentication (SMS). In our experience this is pretty common. 

Given that the farm of engines being used in the attacks were genuine app instances running on emulators then it should also be clear that app authentication, which in the background checks both the app and the environment it is running in, would have detected this particular setup. This should be a central part of your defenses.

Note also that although we have used an attack against financial services institutions as our example in this article, other sectors are equally vulnerable, as illustrated by the healthcare security research we recently published.

Two-factor authentication was a solid start some years ago. Now it’s time to up our collective security game and add multiple different factors to authenticate, some visible to make customers happy and some invisible to make attackers unhappy.

Photo by Michael Steinberg from Pexels