More and more banks offer mobile apps for restricted or even fully-blown online banking to their customers. It’s understandable: many tasks that were formerly performed on PCs are now migrating to tablet computers and smartphones. There is clearly some demand for being able to do typical banking tasks on those devices as well. And interestingly, while most banks got rid of their dedicated online banking applications for PCs over the years, replacing them with browser-based solutions, the opposite is happening now in the mobile world: Rather than simply providing special Web views in existing online banking tools, tailored to touchscreen operation and smaller screens, the standard approach is to take advantage of the higher degree of control over user experience offered by dedicated apps.

This trend is also interesting from a security standpoint: How well do the authentication mechanisms established for PC online banking translate to the mobile world? Are there new methods required to protect accounts from intruders, to protect payment orders from tampering?

While performing this analysis for a customer, we soon concluded that all the known authentication mechanisms used for protecting traditional online banking fall into three groups when it comes to their use in the mobile world:

  1. Not an option

  2. Cumbersome

  3. Usable

The “not an option” group consists of display devices which are plugged into a PC’s USB port and create a secondary, secure channel to the bank’s server. Transaction details are then received through this channel and displayed to the user for verification. Tablets and smartphones typically don’t have a USB port that can be used for this purpose, so these display devices can’t be used for mobile online banking.

The “cumbersome” group consists of all those one-time-password lists, tokens, card readers and display cards which are in use by most banks today. Additionally, a growing number of devices specifically targeted at mobile devices appeared over the past few months: secure displays which plug into a mobile’s phone jack, or use a Bluetooth connection to bridge those last few centimeters between the internet hub (the tablet or phone) and the device. What all those solutions have in common: The user has to bring them along, in addition to the mobile device itself. Hence the “cumbersome”: The wonderful thing about a smartphone is the fact that it combines so many things, from phone to MP3 player, from camera to navigation device, in one compact package that is easy to have with you at all times. Having to carry a second (and third and fourth if using accounts at multiple banks), similarly-sized device for the sole purpose of securing the few online banking interactions a user might do each month very much defies this.

“Security is much more important than convenience”, you might say, but in our experience, a mechanism’s real-world security effect is a combination of both its absolute security capabilities, and its convenience of use, which ensures that it is actually used in the first place.

Which brings us to the third group, the one we deemed “usable”: This group is surprisingly small, it only consists of 4 different technologies:

  1. Username / password: There is not much more left to say about it. It’s of course very convenient, but due to most users’ insufficient personal password hygiene, must be considered highly unsafe.

  2. SMS transaction validation: Users receive a text message, which contains details of the transaction, as received by the server, along with a code. By entering that code in the banking application, they confirm the transaction details are correct.
    SMS transaction validation got a bad reputation lately because cases became known where attackers actually managed to gain control over both a victim’s PC-based online banking session as well as the victim’s phone, and were able to tamper the verification SMS in a way that allowed them to perform fraudulent transactions in the victim’s name. It’s probably only a question of time until the same attack will be seen on mobile online banking. But for the time being, because the effort is very high, and because there are much easier targets, we still consider SMS transaction validation adequately safe, both for PC and mobile online banking, if combined with additional security mechanisms in the back-end.

  3. Secure channel through separate app, such as Entersekt or KOBIL AST: A secondary app, besides the banking app, establishes a direct, secure channel with the bank’s server, and through that channel the transaction details received by the server are re-sent to the user for verification.
    We consider this an interesting approach, its security hinges of course on the way these apps can protect themselves, including their cryptographic key material, from specifically targeted malware attacks on the users’ phones.

  4. Secure channel through SIM-card, such as Swisscom’s Mobile ID: Similar to the secure channel apps, but the key material as well as the program code for receiving and displaying the verification data is securely stored on the phone’s SIM card.
    We like this approach a lot, since it removes all sensitive information and code from malware’s reach. The secondary verification channel operates at a different level from what malware could gain access to. Unfortunately, this is currently only supported by one out of three Swiss mobile operators. But once this becomes more widespread and available to users regardless of mobile operator, we see a big potential, also because the technology is available as a service to all application providers.

All those systems are in use today, specifically in online banking, although not always with a focus on mobile banking. We would have expected to also find some server-side evaluated biometric authentication methods used for this purpose, but in the end had to conclude that none seem to have reached market maturity yet.

From a security purist perspective, using the same device both for banking and as the end-point of a second, secure channel is an added risk. To attack a banking system protected by SMS transaction validation or secure channel apps, a malware only needs to bring a single device under the attacker’s control. This can be mitigated by relying on moving everything sensitive to the SIM card, or by taking additional measures on the server side. The latter is something we recommend in general, not the least due to the sparse availability of usable authentication methods for mobile online banking we observe: Apart from improved authentication and transaction validation mechanisms, banks must also build up additional measures on the server side, such as anomaly detection, to protect themselves and their customers from attacks. That will be the topic of a later article.