A Password-Less World

While it’s all the hype these days to breathlessly discuss eliminating passwords, passwords remain commonplace and nearly ubiquitous, despite agreement across the board that passwords, when used alone, remain the weakest link in the security chain.

What would a password-less world look like? Putting the hype aside, realistically it’s:

  • Irresponsible
  • Costly and not available to every participant
  • Not going to happen anytime soon; over 300 billion passwords to manage

What could go wrong? Let’s explore.

There are many companies, organizations/coalitions, and industry experts working on bringing forth password-less technologies. One of the positive goals of this effort, alongside heightened security, is that by minimizing the amount of steps in the authentication process, secure logins are more convenient for users. There are many technologies today that can be used to achieve that, including SMS, OTP, FIDO/FIDO2 (CATP), biometrics, and other proprietary technologies.

To access this loop successfully, the user must have something on them such as a Smartphone, USB Key, a PIN generator, or something that they are, such as their own fingerprints or other biometrics. The server where the authentication must take place requests from the user their PINs, fingerprint, keys etc., and validates this information by calling the third-party provider of these password-less technologies. The vendor then provides the final positive or negative answer back to the server. At that point, if successful, the user is allowed to access the system.

What could go wrong? The main issue using these technologies is the requirement of using a third-party validator, and trusting that they are going to provide the correct answer. This creates an inherent reliance on their technology, as well as each member of their staff. It only takes one bad actor in a company to create havoc. The second main issue is that this third-party vendor can impersonate the user without their knowledge. The third-party validator will have no problem generating the PIN or token or returning a false positive to the system and thus providing the final positive validation to the server in the authentication process. Doing that, the vendor can access the system and access all the user's data. It remains a huge security risk and in the realm of possible breach points.

In other articles we’ve discussed more about the pitfalls of third party devices in greater depth. There are also time and cost issues associated with third party devices, as well as accessibility constraints.

But “risk” is exactly what is in contention here by removing the “something you know”? And the subsequent question is, how can that risk be eliminated? What is your company’s risk tolerance, truly? And even that of the individual user? The answer will surprise many - by using a password. If a third-party vendor tries to impersonate the user, they don't know and will not have the password necessary to complete the authentication process. That's why we continue to question the experts that are trying to bring us this password-less world. It is possibly irresponsible and devious, akin to hiring the proverbial fox to guard the henhouse.

In addition, assuming that this wave will continue, realistically it will take many years, 10-20 even, given the propensity for slow adoption, because there are over 300 billion passwords in use today, and changing the behavior of users is not easy to do. To facilitate adoption also requires that every platform must adopt higher standards and more sophisticated procedures, and frankly many of them can’t or simply won’t due to technical inexperience or lack of skills, costs, user friction and other obstacles.

The best and many experts agree: the ideal solution is to use both: a password and a 2FA / MFA combination. The 2FA brings the extra level of security, especially if someone knows your password, and the password will eliminate the risk that the 2FA/MFA provider can impersonate you or share that data with others to do so.

Comments are closed