By Tim Callan, Chief Compliance Officer, Sectigo
The term “passwordless” is a trendy marketing buzzword with no shortage of vendors claiming to offer this type of solution — for good reason. Remembering a password is difficult and unpleasant, password resets are time-consuming and don’t always work correctly, and password problems reduce employee productivity and create too many help-desk tickets. Perhaps most importantly, this form of authentication is outdated and insecure.
Whenever a category like this proves exciting to technology buyers, many types of vendors try inserting themselves into the conversation. The term gets stretched and twisted to fit adjacent categories, diluting the original meaning. As a result, many vendors are actively discussing their “passwordless” solutions when in reality they are offering technology products that are not passwordless.
That fact that large swathes of the enterprise now live remote lifestyles magnifies the need for better, more secure authentication, which is where passwordless authentication comes in. But how do you know when an environment is truly passwordless?
Passwordless is not a user experience; that’s just a by-product. Passwordless is an architecture. It’s a strategy.
It’s important to realize passwords can exist even if the authentication system doesn’t require the user to remember them and enter them into a form. Removing this user requirement is certainly an improvement that can benefit employee productivity and reduce strain on the help desk. However, if a password or other shared secret is present, security vulnerabilities remain.
What Is a Shared Secret?
To be truly passwordless, the solution cannot leverage shared-secret-based authentication. A shared secret is the oldest form of authentication used by humans. It’s a specific piece of information that would be improbably difficult to guess unless you have been told what the secret is. If both parties know the secret, they can use it to confirm their rights to access or privileges.
Think about the speakeasies you see in movies. If someone wants access to an establishment, that person knocks on the door and a gruff employee on the other side asks, ‘What’s the password?’ The would-be attendee states the password, and that’s considered sufficient to allow access. This is a shared secret in its simplest form. Shared secrets in computing environments are communicated in different ways, but they follow the same basic strategy. Each side knows and is expecting to communicate the same piece of information. Passwords are the most common form of shared secret in computing environments.
With Shared Secrets Come A LOT of Security Vulnerabilities
Passwords and other shared secrets run a variety of security risks:
- Brute force and dictionary attacks
- Password reuse and credential stuffing
- Login credentials sold on the “dark web”
- Phishing
- Social engineering attacks
- Key logging
- Screen scraping
- Malicious actor-in-the-middle (MITM)
Eliminating the need for humans to choose and remember passwords can mitigate some of these vulnerabilities like reuse and dictionary or brute force attacks. However, it will not eliminate the full set of vulnerabilities associated with passwords.
Many so-called “passwordless” solutions simply hide passwords that are still in place. That makes these solutions a form of password manager or vault. Some use single sign-on (SSO) and other password abstraction layers, while others bury passwords in scripts and various automation approaches. Instead of passwordless, we could call these pseudo-passwordless or less password solutions.
Again, these types of solutions offer better user experiences because a user does not have to remember and enter a password, but don’t confuse them with being passwordless from a security perspective. The vulnerabilities that come with passwords are still there:
- Buried passwords are still passwords.
- Password abstraction layers still use passwords.
- And ultimately, shared secrets are still present.
Proof of identity must come from another mechanism. The only practical mechanism to provide that today is digital identity through public key infrastructure (PKI) technology.
True Passwordless Architecture Is PKI-Based
PKI is based on a cryptographic architecture of private and public keys (asymmetric secrets) and prevents the many problems associated with passwords. The private key looks like a long string of apparently random numbers, and based on a pre-understood algorithm, it can be used to calculate what is called the public key. This is a different, long string of apparently random numbers.
The encryption algorithms are special in that there is no way to use a public key to calculate a private key. So, the public key can be shared with anyone, and the private key is still safe. At the same time, only the holder of the private key can decrypt anything encrypted with the public key.
By attaching PKI-based digital certificates to the identities of users and the machines (i.e. software, devices, bots, etc.) used in an environment, enterprises can implement a passwordless architecture that ensures all digital actors have the access and permissions CISOs want them to have. However, doing so is not just about cryptographically ensuring the identity of a device or server, because IT teams also need to ensure that the person using the device is the intended user. Doing that requires a PIN.
In the authentication world we have an expression, “The thing you have and the thing you are or the thing you know.” We need two of these to be established to safely use passwordless authentication. In this case, a device that is cryptographically proven to be the possession of the person granted access or permissions is “the thing you have.” To use this device you need to be able to unlock it with a PIN or its equivalent, or a biometric. That is “the thing you know” or “the thing you are.”
Understand that PINs and PIN equivalents are not passwords. A PIN does not leave the device on which it’s stored. PINs simply grant access to devices for their proper owners. Because the secret never goes out across a network, password attacks don’t work on PINs.
Plus, to reduce the burden of help desks, strong automation alternatives are available via Certificate Lifecycle Management (CLM) to provision users and renew certificates before expirations, freeing up time for the support team.
This is a passwordless architecture, and it is maximum security.
The Path Forward to True Passwordless
True universal passwordless authentication will be impractical for many organizations in the foreseeable future, because some existing systems will be prohibitively difficult or expensive to make passwordless. This includes some legacy systems that simply may not be able to support PKI-based authentication under any circumstances.
Keep in mind there are still things enterprises can do to improve security. Consider a phased or hybrid approach. Take inventory of systems that do support asymmetric secrets – true passwordless – and those that don’t and look for the closest possible solutions.
Evaluate the relative risk of various systems, processes, environments, and departments and then implement passwordless in pieces following a “greatest bang for the buck” strategy. In these cases, enterprises may still be able to pursue a “less password” strategy. For example, some systems might not support asymmetric secrets but might support symmetric tokens with some form of SSO. This will lessen the pain of passwords where they can’t be eliminated. The user experience will be better and more secure with less support issues.
As problematic systems are updated, this is the opportunity to add passwordless to them. Do not fall for the lowest common denominator fallacy, which is “if I can’t implement passwordless everywhere, I won’t bother implementing it anywhere.”
Passwords are crossing the network every second of the day and will inevitably get into the hands of bad actors. Even if they must be used in some places, try to minimize the risk that comes with them. CISOs need to be creative but take a careful inventory and do the homework on those systems. For some use cases “pseudo-passwordless” may prove good enough, while others may require true passwordless. Be sure you understand the difference.
About the Author
Tim Callan is the Chief Compliance Officer of Sectigo. He is responsible for ensuring the company’s CA practices conform to industry and regulatory requirements and the company’s published Certificate Practices. Tim has more than twenty years’ experience as a strategy and product leader for successful B2B software and SaaS companies, with fifteen years’ experience in the SSL and PKI technology spaces.
Tim can be reached online at LinkedIn and at our company website https://sectigo.com/contributors/tim-callan
