Although passwords are being defeated over and over, most websites and applications still rely on them. Authentication is one of the most used features: millions of websites, billions of users, all the time. The size of the potential market alone – if authentication could be monetized that way – explains why there are so many innovations, patents, technologies, and startups trying to “hack” authentication. Yet, despite all the selfless creativity spent on the topic, passwords are still there. Moreover, like the universe, their inflation is accelerating. Why? The experts have a ready answer: “There’s no ideal authentication solution”. What do they mean, and with all the time invested, how is that possible?

Just an excuse?

Let’s first exclude the situations when this statement is only used as an excuse, by authentication vendors instead of a fair “We know our solutions have flaws x/y/z”, but also by portals or Apps instead of a fair “unless we’re regulated or hit by fraud, why should we bother implementing additional security”. What makes user authentication a (truly) difficult question to solve?

Authentication security wasn’t an issue

Password-based authentication is a design flaw of the Internet. In the time-sharing systems of the 1970s, in systems used prior to the web (such as the French “Minitel”), and in mobile telephony networks, although users only need a password or a PIN to authenticate to their session, there’s an additional, underlying, and hidden verification performed. The user connects from a console on the campus, or using her subscriber landline, or using her subscriber identity module (that’s what “SIM” stands for). Initially, there’s no way in these systems to connect from anywhere and any device.

By making it possible with the Internet, we have at the same time renounced to the more secure form of authentication that this lack of flexibility conveyed; it’s no longer built-in and invisible. The whole authentication journey is about getting back to the “Garden of Eden”: the flexibility and openness of the Internet, the security we enjoyed with closed systems, enforced in an invisible way. Why is this journey a hard and cumbersome one?

Security vs. Universality

Any authentication technology faces 2 major constraints: security and universality. Security means “doing better” than a user-defined password. Universality means that it can be used (in an affordable manner) by anyone, from anywhere, on any device, with any service. So, strictly speaking, there’s indeed no ideal authentication solution since having a single password for all services is definitely the most universal solution, but at the same time the least secure one. All solutions are compromises on universality, on security, or on both.

For example, SMS-OTP (one-time security codes sent by SMS) assume that you are a mobile phone subscriber, that you have your phone with you and it’s charged, that there’s a reasonable mobile coverage by your carrier and no congestion in its network. Provided you’re always located in a dense area, this is a minimal assumption, and therefore a quite universal solution under this condition. But it’s not inexpensive (in most countries). And it’s not secure since it can be (and has been) bypassed on a large scale. Keychain tokens or smartcard-based systems provide a good security but only to the few users that have been equipped with these systems, usually at high costs, and can only be used with a small set of services. “Soft-tokens” have a better security than SMS-OTP (although there’s nothing granted, as discussed in a previous post) but require a smartphone, as well as the installation and operation of a security-dedicated App. Biometry needs sensors that most of us aren’t equipped with, have (still) average success rates, and raise privacy or security (revocability) questions.

We could go on and on. A constant pattern is that universality and security are, to a large extent, conflicting objectives. Hence the need for a compromise. Hence the statement that “there’s no ideal solution”. So, we can’t complete the journey yet, but how far can we get?

Necessary compromises

First, to be universal, a solution must leverage existing capabilities (of users or devices) rather than require to distribute something or ask users to get equipped with something, be it a mere plugin or App: security isn’t a user feature, so most users don’t care about your risks and don’t want to cooperate in managing them. Said differently: build your Apps, services, and user interfaces using authentication SDKs leveraging existing capabilities of devices (tablets, cell and smartphones, desktops and laptops…) so that you don’t have to ask anything specific to users.

Second, devices are (and will remain) diverse, users have an increasing number of devices they want to access your services from. This calls for the use of authentication platforms that are natively multi-method in order to support users whatever the devices they have at any point in time, multi-device in order to accommodate the various devices and channels used to access your services, and have built-in and secure recovery and enrollment methods since the day-to-day operations of authentication is about supporting users having new, lost, broken, or stolen devices, and forgetting their PIN; you don’t want authentication to be the main topic handled by your customer services agents.

Third, built-in device capabilities such as biometry (fingerprint sensors, iris scanners…) or trusted execution environments are (very) long to appear in any given user base. So you want to consider platforms that can provide today a higher security level without requiring these advanced devices capabilities, and are evolutive enough to leverage such advanced capabilities as they appear in the user base.

How about risk- or context-based authentication you may ask? Note that it won’t improve the security or the universality of an authentication solution. It may improve the convenience of the authentication solution, in particular if using that solution is cumbersome, but only marginally otherwise.

The Graal of a universal authentication platform

This is where the authentication journey heads to: SDKs supporting natively all current user devices in a highly secure manner, leveraging additional device capabilities as they become available; a multi-device, multi-method platform, with self-recovery features. It’s obviously an open-ended journey, but also a good way to evaluate the authentication solutions that you’re using or that you project to use. At inWebo, this is the journey guiding our Product vision.