Multi-factor authentication has become a lot less expensive in the last 5-7 years due to the possibility to replace hardware tokens with mobile Apps, aka “soft tokens”. inWebo was one of the pioneers of this (r)evolution as early as 2008. But this missed a hard fact: since the generalization of WiFi, users accessing applications protected by multi-factor authentication do it almost exclusively from their own device(s) such as laptops, tablets, office desktops, and home computers, not from the public shared computers in Internet coffee shops. Another reality is that these applications – even VPN – are increasingly accessed through a browser interface.
Browser based authentication from ideation to realization
When we combined these 2 facts, back in 2009-10, we realized that browser-based authentication would make huge sense since it would make users’ life easier in 95% of the authentication situations, confining the use of tokens or Apps to the remaining 5% (authentication from unknown devices, registration of new devices). Indeed, mobile-based or token-based authentication are an unnecessary task requested to users in 95% of the cases! All this assumed obviously that the security obtained with browser-based authentication could be equal or superior to that of mobile-based or token-based authentication.
However, the right technology for that was just not there yet. It was possible to develop browser-dependent – usually native – plugins or even Flash plugins in order to add multi-factor authentication capabilities to browsers. And it was acceptable in terms of security. So we did it. Unfortunately, it rapidly appeared that the approach was neither manageable from a customer organization perspective (distributing plugins was not much better than distributing tokens as it turned out), nor sustainable from a vendor perspective (due to the fragmentation of the browsers and OS, and to the lack of compatibility between successive versions such as IE6, IE7, and IE8). So the technological prowess never translated in adoption or traction. Finally, the launch and rise of the iPad and its clones, both in the consumer and the enterprise segments, finished to transform this journey into a dead-end, since most of these new devices did not – and still do not – support browser extensions.
However, hating to disappoint customers made us dig further. Luckily, we saw light in the tunnel when html5 browsers started to generalize in 2011-12, making it possible to develop secure multi-factor authentication capabilities for browsers, which would be altogether more manageable because they did not require plugins, and would address the smartphones and tablets’ browsers. Three birds with one stone!
inWebo Helium was released late 2012 and became an instant success. The name for this ultimately light and secure authentication method was chosen because Helium is the lightest non-flammable (!) gas.
Mobile-based authentication makes sense too
Meanwhile, mobile-based authentication had improved. The early offline cumbersome one-time password generators developed when J2ME MIDP was still the dominant mobile platform became connected mobile Apps, embracing push notification frameworks when Apple, Google, and Microsoft released them. inWebo Authenticator replaced the original inWebo nCode application. Mobile-based multi-factor (re)gained popularity.
However, the market reaction was not an overwhelming migration to mobile-based authentication. The main reason is probably that organizations demand flexibility, and mobile-only authentication is a constraint. For instance, how do you address situations where only a fraction of your users have compatible smartphones? As a business, if you equipped the users, you might know what their devices are at a given time and provide appropriate authentication methods to each segment (good luck with that…). As a service provider, you have no clue.
It explains to a great extent why hardware tokens have resisted so well in the market, despite both mobile-based and token-based authentication require from users much more than what is actually needed. Another approach was still needed…
Converged and flexible authentication
Realizing that, we opted for a mixed and flexible approach in our solutions: if a user is connecting from one of his devices enrolled with the inWebo Helium capability, he can authenticate that way without any further. He needs no token or smartphone. This covers the vast majority, if not all situations. If the connection is not made from a known device, this is dynamically detected and he can use inWebo Authenticator instead. As per customer-defined policies, users are able to use the browser-based authentication method, the mobile-based, or both.
Mobility, flexibility, nothing to distribute or to manage, good security, no need to segment users based on their (current) devices, automatic use of the easiest available authentication method in any situation… There is really no flaw in this approach.
But a final touch was needed. inWebo Authenticator and inWebo Helium were still quite different products from a user perspective, due to their different origin and history. In particular they required a distinct enrollment process. Virtual Authenticator fixes it. This is the continuation of Helium as a very convenient, manageable, and “tokenless” browser-based authentication method. But it now shares a common and unified user experience with inWebo Authenticator.
Long life Virtual Authenticator!