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.
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.
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:
All of the above use cases should be reviewed in detail and the risks and consequences of each thought through carefully.
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:
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.
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.
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.