Passwordless Authentication and SAML Identifiers

October 14, 2020

In this post:

InCommon Technical Advisory Committee Updates: SAML Identifiers, IdP as a Service
Passwordless Login Discussion: Community Architecture Committee for Trust and Identity Update

How to Join an InCommon Advisory Group

Working groups are open and you are free to join a working group meeting at any time by joining the mailing list and attending a meeting. Working groups are a great way for folks new to the community to work alongside long-time members to contribute back. Visit the Working Groups list to find a group to join.

Advisory committees open nominations annually in October and terms last for three years. Serving on InCommon committees is an excellent way to serve the community, broaden your professional network, and develop and hone leadership skills. We invite you to nominate people for membership, including self-nomination. Nominations close on October 23, 2020, and new terms start January 2021. To submit a nomination please fill out the Advisory Committee Nomination Form.

InCommon Technical Advisory Committee Updates: SAML Identifiers, IdP as a Service

The InCommon Technical A dvisory Committee (TAC) will continue to lay the groundwork for adoption of two new subject identifiers (general purpose and pairwise) to replace existing problematic ones. Discussion is about to kick off on InCommon adopting, either in whole or in part, the revised SAML 2.0 Deployment Profile (a.k.a., saml2int). Analysis of current best practices within the federation will inform the discussion, which will include identifying the criticality and importance of specific elements and ways to incentivize adherence. Stay tuned for an announcement to be made shortly before 2020 CAMP and ACAMP about a TAC-chartered community working group focusing on federation testing tools.

Highlights of Current Work

Shortly after the pandemic began, the TAC directed its attention towards the recommendations for future work in the Deployment Profile Working Group’s Final Report. The group was chaired by Keith Wessel (University of Illinois-Urbana-Champaign), now vice chair of the TAC, to address the problem of existing standards and profiles being flexible but open to interpretation and so resulting in lack of interoperability. Items the TAC has spent the most time on are federation test tooling and subject identifiers. Creation of documents comparing the characteristics of identifiers currently used in federation and IdP and SP strategies for choosing and implementing SAML2 identifiers consumed most of the TAC’s work cycles.

Notably, the IdPaaS Working Group finished its final report, which the TAC has in hand for review. The group’s co-chairs are TAC member Mary McKee (Duke) and E.J. Monti (Duquesne).

Much of the content the Streamlining SP Onboarding Working Group (concluded September 2018) produced is being incorporated into an expansive update of the Federation wiki. The content will help ease the entry of commercial service providers into InCommon.

The TAC coordinated InCommon’s response to the revision of the NIST 800-63C Digital Identity Guidelines, which was submitted to NIST in August.

For additional details on these works items and other TAC activities, please see the public meeting minutes.

Passwords.

We all know the story. Passwords are evil. But they’re a necessary evil, right? Perhaps not… Here’s an overview of the passwords story, where we stand now and where we are likely headed.

Ask any security professional for an opinion about passwords, and you’ll likely get an earful about their problems:

Passwords are hard to choose. People make lousy random number generators.
Passwords are hard to keep secure. They can be guessed or stolen without their owner’s awareness.
Passwords are hard to remember. People are bad recording devices, and the cost of password recovery remains one of the major expenses in many IAM shops, even now.
Passwords are cryptographically vulnerable. Given a stolen cache of hashes, an attacker can compromise even seemingly “strong” passphrases with modern GPU hardware in a matter of hours or days.
People tend to re-use passwords in disparate (and not always security-equivalent) contexts. Password compromise tends to spread as a result.

Historically, our approach to the “password problem” has been one of mitigation:

Use password safes, password complexity rules, and password generators to make people use “stronger” passwords and make them less dependent on their human memory.
Add multi-factor authentication (MFA) solutions on top of passwords for an extra layer of security.
Employ increasingly complex hashing algorithms to combat increases in attackers’ ability to crack passwords.

Seldom, though, have we addressed the issue head-on by actually contemplating ways to eliminate passwords altogether, because, despite their flaws, passwords have a few hard-to-deny advantages:

Passwords are easy to understand. Users are familiar with them. Security professionals understand them. Auditors recognize them. They’re the devil we know.
Passwords are easy to implement (although not always easy to implement well). Most existing software systems have some support for password authentication.
Passwords are (sometimes) easy for users to use. (long, complex passwords and handheld devices notwithstanding)

If we’re to escape from the password “box” we’ve been in for decades, we’ll need to find alternatives that can solve the problems inherent in password use — that provide enhanced security without enhanced user complexity, avoid the cloning and cracking problems that passwords typically exhibit, and defeat password reuse without undermining ease of use. They’ll need to provide similar advantages to those passwords offer — ease of use and implementation, clarity and understandability, and portability.

Passwordless Authentication Models

Enter modern “passwordless authentication” mechanisms. Passwordless authentication is essentially what it sounds like — user authentication that doesn’t rely on memorized passwords to establish the user’s authenticity.

We’ve actually had early models of passwordless authentication for quite some time. X.509 certificate-based authentication during TLS and SSL handshakes has been around for well over a decade; SSH private key authentication has been around nearly as long. Both of these amount to a kind of passwordless authentication — using public/private key pairs, they allow systems to authenticate to one another (either on their own or on behalf of their users) without using passwords. They have failed to fully supplant password-based authentication mechanisms for user authentication for a variety of reasons, mostly having to do with convenience and ease of understanding.

More modern passwordless authentication mechanisms take advantage of some of the same underlying technology that earlier passwordless authentication strategies use, but they add features and capabilities that make them more portable, more secure, and easier to use.

At their heart, modern passwordless authentication mechanisms still depend on strong cryptography, but instead of relying solely or primarily on memorized shared secrets, they rely on other factors to achieve authentication. If you’ve worked with multi-factor authentication, you’ve probably encountered the basic three-factor model for authentication, in which authentication can be accomplished using one or more of three “factors”:

Something you know (a password, a passphrase, the answer to a question)
Something you have (a device, typically with some cryptographic token to uniquely identify it)
Something you are (biometric factors — what you look like, how your voice sounds, how the whorls of your fingerprint are arranged)

Traditionally, authentication has relied heavily on the “something you know” factor (passwords), and occasionally employed one of the other factors (typically “something you have”) to implement two-factor authentication.

With the proliferation of intelligent devices with significant computing power and interactive hardware — finger print readers, cameras, etc. — it’s become feasible to consider using the latter two factors — “something you have” and “something you are” to achieve strong authentication without the use of passwords. In essence, this is the story of modern passwordless authentication mechanisms.

A Look at Implementations

Various implementations are available today for passwordless authentication. Some apply in local contexts — if you’ve ever used TouchID or facial recognition to unlock an iPhone or used a gesture or scribbled pattern to unlock an Android phone, you’ve used a kind of local passwordless authentication, In these cases, the traditional password authentication approach (often using a terrifically weak 4- or 5-digit “pin” as the password) has been replaced by a non-password-based mechanism.

These local authentication mechanisms are all well and good — they’re convenient and they enhance security over simple PIN solutions — but they’re only useful for unlocking individual devices. What about extending passwordless authentication to web applications and client-server environments?

In the last 12-18 months, we’ve seen the development of a number of passwordless authentication mechanisms, both proprietary and open standards based. Major cloud providers, including Google, Microsoft, Apple, and Amazon, have all announced passwordless authentication mechanisms for some or all of their services. For the most part, these solutions have been internal to their respective ecosystems and somewhat proprietary. Simultaneously, an open standard for passwordless authentication — FIDO2 — has been ratified by the W3C.

FIDO2 and WebAuthn

FIDO2 encompasses two broad protocol standards — WebAuthn (which standardizes a passwordless protocol for web browsers to authenticate their users to web applications across a network) and CTAP (the “Client to Authenticator Protocol”, which standardizes a mechanism for devices like mobile phones and OTP tokens to communicate with clients).

In broad strokes, the WebAuthn model involves two inter-related processes — a “registration flow”, which is typically only performed once and results in the user constructing a unique public/private key pair for use with a web-based application and storing the private half of the key pair in some device (which is then termed an “authenticator”), and an “authentication flow” during which the user actually authenticates to an application via a supported client. The CTAP standard allows portable devices to be used as authenticators and to portably provide access to a user’s keys across a variety of different browser clients, and allows browsers and applications to enforce security requirements on those devices.

A typical user experience with FIDO2 might look something like this:

The user visits a web-based application, authenticates with whatever authentication mechanism is currently in use (probably a password and potentially some form of second factor) and indicates an interest in enabling passwordless login.
The application initiates the FIDO2 registration flow, which triggers the user’s browser initiating a key generation process. In some cases, the browser may be co-resident on a device (like a laptop equipped with a fingerprint reader or with facial recognition capability) that can directly act as an authenticator. In other cases, the browser may call out to an authenticator via the CTAP mechanism (a mobile phone with some biometric or gestural unlocking mechanism, or a physical token that supports the CTAP protocol).
In either case, the key generation process results in the user completing some verification process (usually either biometric or gestural) on the authenticator device, and storing a private key securely in that device. It also results in the application receiving and storing the user’s private key, and associating it with the user’s already-authenticated identity.
On subsequent visits to the web application, instead of providing a password and some second factor to log in, the user can choose to use WebAuthn. Instead of entering a password, the user’s authenticator prompts the user to unlock its key store (using a fingerprint scan, a facial recognition, etc.). Once unlocked, the authenticator then uses the application-specific key to sign a challenge sent by the application, which can then use the public key acquired during the registration process to validate the user’s signature and complete the authentication process.

This approach to passwordless authentication has a number of advantages over both password-based authentication and earlier non-password-based authentication mechanisms:

Enhanced security. Because the CTAP protocol allows applications to require the use of a PIN or some biometric/gestural process to “unlock” the authenticator’s key store, and because the private key is generated on and never leaves the authenticator, the mechanism is intrinsically multi-factor. The authenticator acts as “something the user has”, while the unlocking process acts as “something the user is (or possibly, something the user knows)”. The FIDO2 standard mandates strong cryptography for the creation and storage of keys.
One-step user login experience. Users can achieve the enhanced security of multifactor authentication without having to go through a two-step login process. From the user’s perspective, the entire process is encompassed by the single step of unlocking the authenticator.
Portability. With CTAP, a user’s authenticator can be a portable device — a mobile phone, or a bluetooth-capable FIDO2 token — and it can be used securely in conjunction with multiple web clients, even including clients that the user does not explicitly trust.
Key uniqueness and revocability. In the WebAuthn model, each user has a unique key pair for each distinct application. There’s no password to be reused across applications, and there’s no central repository of key hashes to be compromised.

When the W3C originally ratified the first revision of the FIDO2 standard, some browser and mobile device vendors were quick to respond with support in their products. Mozilla announced support for WebAuthn in Firefox version 60 in mid-2018. Google followed suit with WebAuthn support in version 67 just days later, and as Chromium-based browsers released new versions based on updated Google libraries, they too acquired WebAuthn support.

Support for the CTAP protocol and for physical authenticators to interoperate with WebAuthn-capable browsers has been somewhat slower in coming. Android devices were early to add CTAP support, as was Windows 10 on certain devices with biometric capabilities (fingerprint readers, etc.). With the release of Apple’s iOS 14 and Safari 14 for the Mac, all of the major mobile phone vendors and desktop/laptop platforms can participate in FIDO2.

Duke Unlock Pilot

Duke University has had a long-running pilot underway since last year, offering WebAuthn support for login at the Shibboleth Identity Provider (IDP) (see the January 2020 IAM Online on this topic. Also, Stanford uses a different method, documented in the November 2019 IAM Online). This has broad implications for users at Duke, where in addition to InCommon and eduGAIN relying parties, users routinely interact with thousands of Shibboleth-protected web sites and applications on campus. Branded as “Duke Unlock”, the pilot has introduced WebAuthn to over 1200 users at Duke so far, and with the advent of support for WebAuthn and CTAP in Apple’s ecosystem, Duke is working on plans to make the pilot available to the campus at large. From the user’s perspective, Duke Unlock:

Provides the benefits of MFA without the inconvenience of a 2-step process
Allows users to access most of their web-based services without ever entering a password (once they’ve registered an authenticator)

From the IT organization’s perspective, Duke Unlock:

Enhances overall security by reducing the dependence on potentially compromisable passwords
Reduces costs associated with password recovery, both by reducing dependence on passwords and by providing a password-free authentication mechanism that can be used to recover passwords if needed
Removes another obstacle and provides added incentive for applications to support SAML

There are, of course, costs to consider:

Users may have difficulty with any change, even if it’s ultimately to enhance convenience and security. At Duke, during the pilot phase, IAM staff have put significant effort into supporting early adopters, and into developing and iterating user interfaces for the registration process and the WebAuthn authentication process.
WebAuthn isn’t entirely free of implementation cost. Applications (like the Shibboleth IDP at Duke) must not only implement the WebAuthn registration and authentication flows in order to take advantage of it, but must also have some mechanism for storing user-to-public-key mappings. While this is not really all that different from operating an LDAP or a Kerberos environment to manage password authentication, it does involve some infrastructure changes.

Likely Futures

Thinking forward to likely futures, given the adoption of WebAuthn by all the major browser and now most of the major mobile device vendors, we can anticipate that more applications will begin to support it directly. That may have significant implications for traditional federations, including InCommon.

The Community Architecture Committee for Trust and Identity (CACTI) has discussed at some length the degree to which the advent of user-friendly, high-strength bilateral authentication mechanisms could impact the value proposition for federated identity. To a certain extent, we recognize that the federation’s success to date has been predicated on the ability of federated single sign-on (SSO) to provide secure and convenient web-based authentication to users throughout the R&E world. As bilateral passwordless authentication mechanisms like WebAuthn become an industry norm, the value proposition for federation may shift more decisively from a focus on authentication — merely letting users log in with one credential across many services — to a focus on trust and identity — providing a fabric over which institutions can securely share authoritative user identity information, regardless of how those users authenticate.

Recommendations

For now, we can perhaps make a few recommendations based on the current state of passwordless authentication and what we expect its future to look like:

If you’re working in the Trust and Identity field, you should probably familiarize yourself with the passwordless authentication space, and particularly with the FIDO2/WebAuthn standard. Even if your institution chooses not to move quickly to implement it locally, your users will increasingly be exposed to it, and will likely begin to have questions about it. There are good resources available online from the FIDO2 project and from the W3C, as well as tutorials from various groups to help you familiarize yourself with the concepts and terms. Two good starting points might be the central pages from the FIDO alliance:
- FIDO2 homepage (https://fidoalliance.org/fido2/)
- WebAuthn site (https://fidoalliance.org/fido2/fido2-web-authentication-webauthn)
Consider the value propositions, both for your users and for your IAM, Security, and support staff of adopting passwordless authentication mechanisms in your infrastructure. Consider whether opening an early conversation about your organization’s stance on passwordless authentication with key governance and other stakeholders may be in order.
Keep an eye out for updates, both from InCommon and Internet2 and in the popular press, about new developments in the passwordless authentication space. FIDO2, as well as some of the more proprietary passwordless authentication mechanisms from major vendors, is still relatively new, and while the underlying technologies are quite mature and well-understood, the interoperability standards are likely to go through more maturation over time.

October Community Update: Passwordless Authentication and SAML Identifiers