As passwordless moves from consumer grade to enterprise grade, organizations are running into concerns as they begin to operationalize the technology.
This piece provides workaround solutions to address common passwordless adoption issues.
4 Passwordless Examples
One way to understand the current passwordless market is to slice it by what you are authenticating with and what you are authenticating into. There are four primary use cases for workforce passwordless authentication today:
- Authenticating into devices, such as mobile devices and Mac and Windows computers.
- Authenticating directly into apps, such as SaaS apps that directly support the FIDO2 standards passwordless standards.
- Authenticating into apps with SSO, such as SaaS apps supporting SAML, or OAuth/OpenID Connect (OIDC) and SSO directly supporting FIDO2 standards.
- Authenticating into on-premises apps with SSO, such as traditional apps supporting on-premises SSO with protocols like Kerberos or NTLM.
Solutions to Passwordless Challenges
Ways to overcome the passwordless adoption issues listed above include:
Authenticating Into Devices
One of the savvy things about passwordless technologies is the biometric data is used as an identifier, not an authenticator. What does that mean? Previously, if using biometrics, you would store the pattern of your user’s fingerprints. You would
hash the pattern at time of enrollment and at time of login capturing their fingerprints, hash that and compare the hash value. This introduced privacy and security risk because the data was stored centrally, and if the data was lost or stolen, the
biometrics would be, too—and people can’t change their biometrics. Often, users wouldn’t want to enroll their data and have it held by the organization or a third party. These user concerns are reflected in today’s regulations
around biometrics.
Passwordless helps address this concern. When users look into a camera on a Windows Hello computer or apply their thumbprint on a MacBook notebook, that pattern of their face or fingerprint
is used to unlock the device and identify them. This unlocks the trusted platform module (TPM) on Windows or the Secure Enclave on the MacBook. Once identified to the device, the device public/private key pair is used to do the authentication. The
biometric data never leaves the device and is never used to directly authenticate to applications or services, successfully addressing most of the security, privacy and regulatory concerns.
Challenges With the PIN
In conjunction with facial recognition or fingerprints, users must set a personal identification number (PIN) to access the device. As with biometric data, the PIN is not the authenticator. The PIN unlocks the cryptographic material from the specific
TPM or Secure Enclave on the user’s specific device.
Issues with the PIN include:
- Adversaries may try to guess or brute-force the PIN: The requirement of having physical access to the device to enter the PIN reduces the risk, because the typical attack vector of remote password spraying is removed. The device must first be stolen.
If stolen, the Windows Hello PIN can only be attempted a set number of times, which reduces the likelihood of brute-forcing. The PINs are not stored centrally, so the attack vector of obtaining a database or list of passwords and using them to identify
specific user credentials is mitigated.
- Users may set easy-to-guess PINs: The default PIN for Apple and Windows devices will not meet most organizational password policy requirements. However, there are two ways to address this:
- Make an exception: An argument can be made that the PIN is not a password and is, therefore, exempt.
- Apply the policy: For Windows environments, it is possible to set complexity requirements around the PIN.
- Users may forget their PIN: Because the biometric or PIN unlocks the device, the default for resetting the PIN is resetting the device. This often means loss of data. With Windows Hello, organizations should set up the Microsoft PIN reset service
to enable recovery. MacBooks will need a platform comparable for enterprise management of Touch ID.
Spoofed Biometrics Risk
Facial recognition has been spoofed many times over the years, spurring corresponding improvements in cameras and algorithms. Fingerprints have been copied and 3D printed to spoof a live fingerprint, and work is currently being done to improve the sensors
and algorithms here, too. Liveness detection addresses this somewhat; although, it has limitations. The direct way to address these concerns is to ensure the equipment meets the requirements laid out by the vendors and to rely on the improvements
in the market.
In addition, such spoofing requires the device to be stolen, which increases the attack complexity. Training employees to immediately notify the service desk when devices are stolen and establishing
processes to remotely wipe stolen devices reduces the time an adversary has to compromise a target.
A broader way to address the risk of spoofed biometrics is to rely on other factors of authentication. This falls under the category of risk-based authentication (RBA) or zero trust access and, usually, uses additional signals, like the device authentication
location and behavior analytics. Should adversaries steal a device and bypass biometrics or guess a PIN, they are unlikely to be at the user’s normal location, accessing applications at the normal time and in the way the legitimate user normally
does. Identifying these changes and preventing access is a strong control for both passwordless and broader credential-theft threats.
How to Solve Shared Computers and Workspaces
The Windows Hello approach depends on a one-to-one relationship between a person and their device. But this relationship creates a challenge for employees who have shared devices. Call center employees, front desk employees or medical assistants are common
examples. In those cases, distributing out the PIN to multiple people creates non-repudiation risks.
The solution here is to use a universal second factor (U2F) key. The person then authenticates to the device with the key instead of with biometrics. Of course, other organizations are delaying passwordless in this scenario, given the perceived complexity
and cost of equipping this portion of the workforce with U2F keys.
A similar issue crops up with hybrid work and the increase in workspace hoteling, where employees use a temporary desk space with the basics, such as docking station, keyboard and display. In this scenario, the one-to-one relationship between the person
and computer is not disrupted. However, a docked laptop means the camera is unavailable.
Windows Hello does support external cameras. The solution to these scenarios is to equip the workspace with a camera that meets the Windows Hello specs and is connected to the docking station. Unfortunately, a similar option does not currently exist out
of the box for MacBook Touch ID with docking stations and external keyboards.
Audit and Compliance Tips
Many security standards and guidelines require a password plus MFA for authentication, and many include guidelines for password length, complexity and rotation. Having no password can pose a
challenge for auditors.
The solution here may be to tie back to NIST Special Publication 800-63B on Digital Identity Guidelines: Authentication and Lifecycle Management. The section to discuss with
internal auditors is Device Authenticators, which is where Windows Hello, MacBooks and U2F are considered.
When planning passwordless initiatives, it’s important to allocate time to educate internal auditors. Also, consider including internal and external auditors on evaluations of passwordless
proofs of concept, where appropriate.
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.