Strong authentication, as we know, must be implemented as a compromise between security and user convenience. This holds for any kind of service, but this is particularly true for mobile, consumer-facing services, because both the mobile device and the large, not tech-savvy audience, introduce specific UX (user experience) requirements. Mobile banking should therefore see ideal implementations of strong authentication. But apparently, something went wrong…

Living with the legacy of e-banking authentication

Banks have generalized the use of mobile phones for authentication around 2007-10, usually as a consequence of regulations about online payment security that required a dynamic authentication. As most retail customers had at least a basic phone, “SMS-OTP” – random codes sent in a short-text message used to confirm a transaction – were seen by most banks as a convenient, secure, and inexpensive way of becoming compliant (SMS-OTP fell short of meeting all 3 expectations, of course, but that’s another story – or post…).

“Soft-tokens” – mobile Apps generating one-time authentication codes – were also rolled out here and there, but never generalized, probably for bad timing reasons: by the time compatible phones were widely available, App banking had already taken off, so banks would never be able to explain to their customers why 2 Apps were required.

Nevertheless, in a way or another, mobile phone has become a widely successful out-of-band second factor in e-banking. Then came m-banking…

Initially m-banking operations were very restricted, because there was no good way to secure sensitive operations: it’s really painful to enroll users in a strong authentication solution, such a solution was already in place, and it had been “designed” (!) for e-banking only. Ironically, banks that had deployed old-style key-chain tokens had a slight advantage in securing m-banking. Those having deployed CAP (Chip Authentication Program) were completely left behind – don’t laugh, some banks still signed up for CAP as late as 2011! (by which you may have guessed that I was living in France at that time…)

M-banking authentication era

Like it or not, authentication for m-banking era can’t be out-of-band. Using key-chain tokens to keep a smell of a separate device doesn’t make any sense as it doesn’t protect from phishing or malwares, so there are really no valid out-of-band options.

in-App authentication has been proposed as the m-banking authentication mechanism. For example, inWebo proposed a SMS-free in-App authentication concept as early as 2010, and released a security-certified product as an SDK in 2012.

in-App authentication makes m-banking security really convenient, as 2FA can be completely hidden to users – the same way in-browser 2FA does it for web sites. But that’s the theory. In practical terms, banks still struggle to make 2FA – and security in general – a seamless experience.

Just one example with … a well-known global bank. I see no need to expose this bank to public irony – first because I’m not sure this post would reach executive ears and ultimately make customers’ life easier; second because one would get the impression by contrast that other banks are performing much better: actually, there’s no winner! Let’s mention that it’s not a 2010 example as you would think, but the brand new, just released, 2013 in-App 2FA enrollment process! So here’s what you have to do, take a deep breath:

sign in to your online account from a web browser create a secrete question and answer – you know, something like “what is the last book you have read?” (you’re not required to rate that book though) download the mobile App enter your credentials and the answer to the secrete question define a password in your online account enter it in the mobile App obtain a first activation code from your online account enter it in the mobile App receive a second activation code by SMS, email or post (yes, post!) enter it in the mobile App define your PIN in the mobile App you’re all set!!!

Half-way reading this list, most of you have probably checked if, by any chance, this post hadn’t been written on April 1st. But unfortunately, it’s not a joke!

However, the exact reason why it’s so f… weird and complex is an open question I address to the audience. I have a few tentative explanations in mind: a) the process was reviewed at all hierarchical levels, each one adding a step, b) they stopped adding steps when they couldn’t figure out additional ones, c) some pre-Millenial consultant suggested that the more steps, the more secure customers would feel.

That last one is probably true. If there are any customer left…