Key Considerations for Password-less Authentication

Eliminating passwords and using other means of authentication such as biometrics or possession-based factors seems to promise improvements in both user experience and security. This piece explores the password-less authentication options available along with the pros and cons of each and offers advice for leveraging non-password credentials in an enterprise environment.

Problems with Password Authentication

Passwords can be insecure (guessing attacks, sticky notes, key-loggers), passwords can be a nuisance to enter, can be hard to remember and can even be hard to choose, because every password change screen seems to have different requirements. Help desks spend an inordinate amount of their time responding to login problems, most commonly due to forgotten and locked-out passwords. Surely there are better ways to authenticate users into devices, systems, and applications?

Authentication Alternatives

Passwords are just one form of authentication, which is any process by which users prove they are who they claim to be. Users can authenticate themselves to a computer system using three main methods:

1. Knowledge factors. These include “secret” information, such as a password, personal identification number (PIN) or answers to security questions.
2. Biometrics. This is when users submit part of their body to measurement, such as a fingerprint, retinal scan or voice print.
3. Possession factors. For these, users prove they are in possession of a physical artifact linked to them, such as a one-time-password device, smart card or mobile phone.

Every type of credential has its strengths and weaknesses, in terms of security, cost to deploy, cost to support, convenience and compatibility. Because of these compromises, it is considered best practice to combine credentials in the authentication process, i.e., use multifactor authentication (MFA).

To eliminate passwords – and knowledge factors more generally – replacing knowledge factors with a combination of biometrics and possession factors is an option to consider. Here’s why:

Convenience may be sacrificed. Interacting with a physical device and providing a biometric sample can be less convenient than entering a password. Moreover, not every combination works for every person, on every device or in every physical context. Examples of limitations include:

• Some methods do not work offline. For example, users should be able to sign into their laptops in an airplane. This means any authentication that only works in conjunction with a network service – such as sending a PIN to the user’s mobile phone or validating a passcode (e.g., using an RSA token or similar) against a network authentication service – is often not suitable for laptop logins.
• Some methods require add-on hardware. For example, smartphones have fixed hardware, so it is difficult or impossible to add a smart card reader to a phone.

Two-Factor Authentication Considerations

If we want to use two factors, and we don’t want to use a knowledge-based factor, it follows that we need to use both a possession factor and a biometric. But biometrics can result in challenges as well.

Not every user can successfully provide every kind of biometric. Examples include:

• Individuals with very small fingers, who cannot use fingerprint or finger vein biometrics.
• Amputees, who cannot register biometrics from missing limbs.
• Individuals unable to speak cannot interact with voice biometrics.
• Visually impaired individuals, who either cannot provide retinal or iris scans (missing or damaged eyes) or have difficulty doing so because they cannot position themselves effectively against the camera.

Some biometrics are sensitive to the physical environment. Examples of these limitations include:

• Limitations outside in very hot, very cold, very windy or dirty environments.
• Face scans often don’t work well in variable lighting or with cameras that generate poor-quality images and generally don’t work when individuals are wearing face masks (e.g., during a pandemic).
• Most PCs do not have fingerprint scanners.
• Finger vein scanners are more robust than fingerprint scanners, but they are usually also much more costly and bulky.

The choice of biometrics used with phones depends on what they include from the factory, which is typically a fingerprint scanner and/or face recognition that works well under ideal lighting conditions but poorly in the dark.

Because of these issues, any use of biometrics should allow users to select from at least two different biometrics and fall back to knowledge factors if no biometric is operable in their context.

Biometric systems have a physical scanner, which acquires some data about the user. The data is compared to a previously enrolled profile of the user, either locally on the user’s device or on a network service. A login session is then established either locally on the user’s device or to a network service. This sequence implies some potential problems:

If the authentication happens on the network, then:

• Biometric authentication cannot be used to sign into the device when there is no network connection.
• Depending on what data is encoded in the user’s profile, theft of biometric profile data from the authentication service could lead to irreversible theft of the user’s identity.
• Compromise of the client device operating system (or even of firmware in the input device, such as a fingerprint scanner, microphone, etc.) could lead to a copy of the user’s data being created when the user performs a login, again leading to identity theft and subsequent successful impersonation.

If the authentication happens locally, then:

• The local operating system must be trusted to securely store both the biometric profile (for matching purposes) and credentials to network services.
• A compromise of the local OS can lead to compromise of the user’s credentials for network services because those are stored locally. In concrete terms, cryptographic certificates and plaintext or decryptable passwords are stored on the user’s device and may be vulnerable to theft.

For these reasons, great care must be taken in protecting the operating systems, device drivers and hardware where biometric data capture, user profile storage and credentials are stored and processed. What might at first appear to be a very secure system could potentially be a very insecure one.

Beyond these considerations, there are also the statistical characteristics of the biometric mechanism itself to consider. What are the false accept rate (FAR) and false reject rate (FRR) exhibited by the biometrics in question? A high FAR is insecure, while a high FRR is painful for users to interact with. Biometric algorithms typically allow for adjustments, which tend to adjust FAR and FRR in opposite directions (lowering FAR increases FRR and vice-versa).

Authentication Frequency Issues

A major problem with passwords is the need to enter them repetitively. The same problem arises with all other types of credentials – having to sign on frequently is still a usability problem, even if the mechanism is not a password.

To minimize authentication frequency, you might consider authenticating users when they sign into or unlock their device and to leverage the device authentication state to seamlessly establish login sessions into applications and services (i.e., using single sign-on, or at least reduced sign-on). There are a few ways to do this, which depend on the type of device and network:

Kerberos/integrated Windows authentication. This works where these constraints are met:

• The user first signs into either a Windows PC or Mac, which is joined to an Active Directory (AD) domain.
• The user’s PC is physically attached to the corporate network (where AD domain controllers are found) or has a virtual private network (VPN) connection to that network.
• The login generates a Kerberos ticket.
• The user signs into a Kerberos-enabled website (such as one running IIS on the corporate network or a SharePoint site) or accesses a Kerberos-enabled service, such as a file share.

Mobile phones are not normally able to participate in Kerberos, so this mechanism is really for corporate-managed PCs on the physical or virtual corporate network.

Federated access: This works where these constraints are met:

• The user signs into a web application.
• The web application has been configured to trust a federated identity provider (IdP), typically via a protocol such as the Secure Assertions Markup Language (SAML).
• The user can sign into the IdP once and leverage that login session to sign into multiple applications. In principle, an IdP service could plug into any authentication scheme, so federated access is suitable for mobile phone access as well.

The two mechanisms above can be linked via a trust relationship. For example, a user might establish a Kerberos login session first and use that session to activate a federated IdP, which in turn enables logins into (web) applications.

Device Authentication Options

Reasonable mechanisms for a user to unlock a device depend on the type of device – meaning what sensors and hardware interfaces it includes and what operating system it runs. The major options are detailed below.

Device: Smartphone

Login Type: Local

Authentication Options:

• Fingerprint.
• Face match (preferably with an infrared light, which is common on modern iOS devices but not on Android phones).
• PIN or swipe pattern.
• (A possession factor is implicit in logins to a smartphone as most users keep their phones on their person almost all the time.)

Access to Network Services:

• Once the phone is unlocked, it is often reasonable to assume that a biometric has already been presented.
• Both iOS and Android expose APIs for an app to prompt the user to provide another, "fresh" biometric.
• When users access a web service, they are redirected to a federated IdP, which may interact with an app previously installed on their phone. The app may either just ask the user to confirm login (assuming the device was already biometrically unlocked) or may prompt the user for a fresh biometric.

Device: Windows PC

Login Type: Local

Authentication Options:

• Windows "Hello" infrastructure with face match, fingerprint or other biometric.
• Smart card inserted into a card reader attached to the PC.
• Key fob inserted into a USB port with a cryptographic payload. Theoretically, this is smart-card-like functionality but with the cryptographic payload on the user’s phone communicating with software on the PC via Bluetooth.

Access to Network Services:

• Once local login has completed, if the user is on the network, a cryptographic certificate-based domain login can happen, which returns a Kerberos ticket.
• The Kerberos ticket can be converted into a SAML or similar federated access assertion to access non-Windows-centric services.

Since these are device authentication options, they should all work when there is no network connection. This also means several mechanisms are not recommended as device login credentials, because they would render the device inoperable when offline. These include:

• Sending a PIN to the user’s personal e-mail address or mobile phone.
• A smartphone app that interacts with a network service.
• Hardware tokens (e.g., RSA SecurID and similar) that validate against a network service.
• Validation of biometric samples by a network service.

Pros and Cons of Password-less Authentication

When architected properly, password-less solutions that include biometrics and/or possession factors can offer both security and ease of use. However, organizations considering this path of password-less authentication should consider the following:

• Understand the context in which users sign in, including device type, device location and network connection status.
• Understand what applications and services users will connect to, both locally on their device and on the network.
• Make allowances for offline users.
• Give preference to device-local biometric validation and certificate storage, over network biometric validation services.
• Support multiple types and combinations of credentials, to ensure users are not blocked from login because a particular type of biometric does not work for them or they misplaced a key device.
• Consider whether all the above really yields a net benefit vs. knowledge factors, or whether incorporating knowledge factors along with biometrics and possession factors is preferable.
  

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.