Deploying passwordless authentication is, essentially, a problem in integration and compatibility. Different types of client devices (Windows, macOS, Android, iOS), managed either by the user or the IT organization,
connect over a network to a variety of services and applications—any one of which may or may not support non-password authentication or, at least, not in the same way.
This piece explains passwordless and other authentication methods and offers recommendations for a well-planned, incremental passwordless deployment.
Authentication Methods
The oldest and simplest form of authentication is for the user to key in a ‘secret’: their password. The system or application compares what was typed to a previously enrolled value
to verify the user attempting to sign in entered the correct string and is, therefore, presumably the one and only person who knows the secret. Using a password is just one of many forms of authentication; others include:
- Knowledge factors: Something the authorized user knows and others do not. Typically, this means passwords, but it can also include PINs and answers to security questions.
- Biometric factors: A measurement of a unique, physical characteristic of the authorized user.
- Possession factors: A physical item the authorized user is expected to carry and other people cannot (easily) acquire.
- MFA: Using two or more of the above three types of credentials (knowledge, biometrics and devices).
- Cryptographic authentication: Also referred to as certificate-based authentication or public key infrastructure, it is a set of mechanisms used to create an authorized session into a network service once a user has unlocked cryptographic key material
on their local device. It’s not how the user authenticates, but rather how local authentication enables login sessions on network services.
- Passwordless systems: These typically replace a single, knowledge-based authentication factor with biometrics, physical devices or both.
Problems with Authentication
Just because passwords have problems, this does not imply alternatives are perfect:
- Users hate having to find their phone or another device just to sign into an operating system or application on their PC.
- People misplace physical authentication devices (phones, hard tokens) or simply leave them behind, at home or the office, where they will not be available when needed.
- Physical devices can be lost, stolen or damaged.
- Biometrics often depend on specialized sensor hardware, which can be costly to deploy, difficult to retrofit to existing computing endpoints and not compatible with every kind of system or application.
- For any given type of biometric, some users simply cannot enroll or authenticate. This includes people with disabilities and other physical impediments. A good general rule is to assume that 1% to 2% of a typical population of people will be unable
to use any given type of biometric.
- Biometrics are often not possible to use because of environmental conditions. For example, facial recognition has issues in the dark or when people wear a face mask, fingerprint scans are difficult in the cold, voice biometrics tend to fail in
loud environments, etc.
How Passwordless Authentication Works
Users typically interact with passwordless authentication mechanisms via the following sequence of steps (a great example of this pattern is Windows Hello)
- Unlock a device with a biometric, which is validated against data stored locally.
- The unlocked device has access to cryptographic key material.
- The key material is offered to network services to sign in without further evidence of the user’s identity.
How this works in detail depends on the type of client device (OS), how it’s managed (centrally or BYOD) and the type of network service being accessed. In short, there is no single solution that performs this sequence in all cases.
Some mechanisms only work when the user’s device has an active network connection (possibly a VPN). They won’t work for someone signing into their laptop on an airplane or while away from cell service, for example. This includes sending the
user a PIN via SMS or using a one-time-password service such as RSA SecurID), where the code is validated by a server on the network. A few
network services support cryptographic authentication directly. However, most do not, and instead:
- Some require passwords: The only practical way to integrate these with centralized authentication systems is via “password injection,” a fragile and inelegant solution. Some questions that must be answered here include: How are passwords
that will later be injected initially acquired? Where are they stored and how are they secured? How are they injected into various login user interfaces? How is the injection mechanism protected against abuse?
- Some can “outsource” their login process via federated access to an identity provider service: This is the preferred approach. The most common federated access standards in corporate environments are the SAML and Open ID Connect (OIDC).
Microsoft also promotes WS-Federation (which no other vendor uses), and consumer-facing applications such as LinkedIn and Facebook often use OAuth.
Keep in mind that well-managed passwords are a useful tool for security; it is poorly managed passwords that give passwords a bad reputation. In addition, authentication using biometrics or hardware devices also has friction, and this friction is
sometimes perceived by users as worse than passwords.
Use MFA To Minimize Problems
Because every kind of credential has its own operational problems, it’s a good idea to combine two types of credentials at login time and give users two or more valid combinations, in case one combination is nonfunctional at a given time, in a given
context or for a given person.
The most common combinations of credentials are:
- Password or PIN plus hardware device (frequently, the user’s existing mobile phone).
- Biometric on device (e.g., a desktop PC or laptop) plus interaction with a second device (e.g., the user’s phone).
- Biometric on a very personal device (almost always a phone), where physical possession of the device is an implicit second factor.
Best Practices for Passwordless Deployment
1. Do Your Planning and Research
Implementing a passwordless strategy is an exercise in integrating authentication services with various systems and applications and overcoming compatibility issues on both client devices and back-end systems. This can be complex, so planning is essential.
Best practices here include:
- Assemble an inventory of client devices, physical/network locations and services that will be integrated with the new authentication system.
- Select biometric and possession factors that make sense for the user community, devices and network connectivity contexts. Multiple combinations will be required. It is recommended to enroll biometric samples and validate biometric user identity
locally on each device and carry evidence of authentication to network services via cryptographic certificates. Validating biometrics on a network service creates a very attractive target for attackers (i.e., the database of user biometric samples).
- Plan to integrate as many apps as possible with Kerberos (on premises/VPN/Windows) or federated access (SAML, OIDC): Replacing authentication schemes is a costly exercise, so it’s best to do it once or twice on shared identity providers and
“outsource” authentication from as many apps as possible to this shared infrastructure.
2. Federate App Logins to Shared Infrastructure
This can be done before passwordless or MFA are deployed. We recommend moving one app at a time over to the new system, because this gives you time to identify, diagnose and remediate any compatibility problems as they arise.
3. Replace Passwords at Device Login Screens
Test with different devices, users and network services, and plan on rapid response to login failures to forestall user revolt if things go wrong.
Deploying an identity provider service, configuring MFA, integrating apps with that IdP and changing client OS authentication to use hardware tokens plus biometrics are all tasks that will require significant time and effort. Validating each part of this
infrastructure, including testing as many combinations of client device type/client state and location/authentication method/IdP login/app login will take time. A small team and a year or more of elapsed time are going to be required.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.