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...