Passwords are prehistory. Passwords are dead. We’re going to end passwords. Sounds familiar? Google probably has millions of results for each of these searches. Yet, for as long as I can remember – since the rise of the World Wide Web at least – passwords have been fingerpointed as the flaw in this otherwise amazingly well engineered system. We’ve also been presented with the solutions to the problem. We love good stories and the tech world is full of them. So, when we hear about a new shiny and ingenious thing being invented to end passwords, or that the big guys in the Valley or elsewhere have teamed up on a password killing mission, well, we believe it’s only a matter of weeks or months before this cruisade is over and we go back to more serious business.
350 passwords – and counting
However, passwords still stick around. I have 350 of them in the password manager I signed up for 2 years ago (Login-Everywhere.com). The cruisade isn’t over. In fact, the enemy has barely been scratched by all the maneuvers launched against him in the 10+ last years. On the contrary, his influence is still growing. Amazing scientific and engineering prowess has taken place in all areas in the same 10 last years, yet we haven’t succeeded in replacing passwords as the main and almost exclusive form of authentication in use. What did we (as an industry) do wrong?
Conflicting views on what to do
Users suffer from password intoxication (too many of them) and hate complex login processes, but this is not the only issue related to passwords: indeed, most experts now consider that passwords are no longer providing the required security level in many different situations. So, ideally, passwords should be replaced by something that’s at the same time more secure and easier.
More specifically, organizations are looking for easier and safer user authentication methods for their applications and implement a mix of multi-factor authentication for some applications, federation and password vaulting for others. It’s somewhat easier, somewhat more secure, but overall, ease-of-use and security don’t marry well. Users on the other hand increasingly use password managers that make their lifes easier but bring little additional security (you can just google articles about the security breaches that hit some popular password managers) and are generally not allowed in the workplace.
Organizations wish they had a self-centric and “secure” authentication, whereas password replacement candidates favored by users – if there’s such a thing! – are rightfully dismissed for risk and security reasons by IT professionals. This explains for a great part why we’re still where we are and why we might still have to live with passwords for a long time.
If you look at it more closely, the failure to make MFA a technology cheered by users has at least 2 distinct causes: first, that it requires additional, cumbersome operations such as copying codes or having to carry tokens. Second, that most applications protected with MFA don’t want to share their MFA method with other applications – MFA works in silo. Users are therefore getting an MFA intoxication that is hardly better than the password one they suffered from; they are one and the same problem since each new MFA method requires the user to memorize yet another “what I know” factor – that is, a password.
But what if we replaced “what I know” factors with “what I am” ones, i.e. biometry. Not only is biometry usually easier and more natural to use, but even when it’s used in silo, it doesn’t bother users. If App A and App B are not using the same voice print data, a user of both Apps hardly notices it.
Biometry can be used in a user-friendly way to enhance security for stand-alone applications, federated applications, and password managers altogether. 2, or even 3 birds with 1 stone!
Implementing biometry: the good, the bad, and the ugly
However, not all implementations of biometry are equal, especially in terms of security and privacy.
A first common flaw is to store the “what I am” factor in a server-side database. On top of being illegal in many countries (in Europe in particular), this usually results in bad performances (sensor data has to transit over the network) and low security (smartphone cameras are now good enough to take pictures of fingerprints on glasses that can be used in replay attacks; voice can be recorded and used in replay attacks; etc.). The best practice is “match on card”. It means that the biometric algorithm should run client-side and compare the input of a biometric sensor with a locally – and hopefully securely – stored print. If the attacker doesn’t have access to a device owned by the user where the print is stored, he can’t make any use of a “what I have” factor that he would have copied.
A second common flaw is to replace password-based authentication with local biometric authentication. At first, it sounds contradictory with what I’ve just said but let me explain why it’s not. Local biometric authentication provides a proof that this is the face, the voice, the fingerprint, the veins, the iris, etc., of a given user. In a client-server implementation, it’s easy to believe that since the biometric sensor has a very high precision, it leads to a secure user authentication process. It does indeed, provided that the proof cannot be spoofed. An obvious case of a lousy implementation is when the local biometric sensor only provides the authentication server with the ID or reference of the user it has identified. Good implementations include sensors providing as a proof a signature of a challenge, such as the FIDO-certified sensors that result in a good security level, provided their private key is well protected by some form of secure element. Other good implementations such as the one provided by inWebo use biometry as the second factor of an MFA and challenged-based scheme, making it impossible to spoof the proof for an attacker who doesn’t have access to a device owned by the user where the print is stored.
Very little is missing
Let me sum it up. The situation is actually not as dark as it seemed. The puzzle of technologies that will replace passwords or at least help push them behind the scene, where users won’t see them, is almost complete. An easier and safer Internet is at hand. The pieces of the puzzle are listed below:
- biometric sensors or libraries…
- with a mach-on-card implementation…
- using a secure, preferably hardware-protected storage of the prints…
- providing local APIs to client-side MFA mechanisms…
- implemented by applications or password managers.
Actually, you can already source most of these technology components from inWebo, as a kit, or assembled for you.