The evolution of authentication, from passwords to passkeys

This blog post is a written version of a talk that our cofounder Maya gave at BSidesSLC in April. You can also watch the recording and get the slides.

Authentication has always been defined by the tension between security and usability. For years, making authentication more secure meant making it harder to use — and making it easier to use meant introducing new security holes. Security innovations used to start in enterprise and trickle down to consumer applications. But now, that flow has reversed, with consumer authentication improvements like TouchID making their way into enterprise environments.

This push and pull between security and usability has been productive as both sides of the equation have improved over time. Increasingly, the best authentication controls we have are the most usable ones.

One thing hasn’t changed: we still need to verify that users are who they claim to be. But how we do that verification has changed: authentication has moved from simple passwords to complex passwords, from islands of identity to federated systems, and from single-factor to multi-factor authentication and passwordless experiences.

Basic authentication: usernames and passwords

Passwords are relatively new. In 1961, Fernando Corbató at MIT created passwords for time-sharing systems where multiple users needed different access levels and private files. This ensured users were only authorized to access their files and use their assigned time on the shared system.

Just a few years later, a doctoral student who wanted more time on that system realized that he could print out the list of all of the passwords, and login as someone else. Turns out the passwords were just stored in plaintext.

To protect against this password theft, Unix introduced password hashing in the 1970s. By using a one-way function (a hash), the system can store enough information to verify that users are presenting the right passwords, without storing, and therefore risk leaking, the passwords themselves.

As the number of systems that a user might need to log into increased, they had a corresponding need for more passwords, and so frequently a user would reuse the same password to authenticate to multiple systems. However, if a user reused a password in multiple places, and any one of those instances was compromised — for example, if the system didn’t actually hash and store passwords properly — then that password could be tested against another system to see if it would give access. Attackers could then use these compromised credentials in targeted attacks against specific users (credential stuffing attacks) or feed them into broader password cracking efforts to expand dictionaries of common passwords and their corresponding hashes.

To make their passwords easier to remember, users started using variations on the same passwords. For example, rather than using the 27th most common password hunter, they might instead use the password hunter2.

Password complexity requirements

To prevent weak passwords like password123, organizations introduced password complexity requirements. Rather than letting a user set any password, users’ passwords had to meet specific requirements in order to make them harder to crack.

When NIST SP 800-63 was first published in 2004, it suggested minimum requirements for password complexity, including irregular capitalization, special characters, and at least one numeral. Although it’s mathematically true that passwords using a variety of characters greater than just lowercase letters should be harder to crack, in reality, many passwords that humans create to meet these requirements end up becoming a predictable ordering of capital letters, lowercase letters, numbers, and symbols, like Password123! or leetspeak like P@ssw0rd!. Meeting specific password requirements can be infuriating.

Password complexity requirements didn’t improve security — they made it worse. Users couldn’t remember complex passwords, so they’d reset them more frequently. And, there often were additional requirements around regular password rotation. An easy-to-remember password is not secure, but a secure password is hard to remember, harder to type, and so less usable. It’s an unfortunate tradeoff.

The current industry guidelines instead focus on password entropy — which is achievable with a long password, like correcthorsebatterystaple — and discourage specific complexity rules and rotation of non-compromised credentials. Security doesn’t have to be completely at odds with usability: rather than a perfectly random password, a fairly random but pronounceable password is much more usable and still more secure.

Password storage has also improved: it’s easier than ever to properly salt and hash passwords. argon2, as the winner of the Password Hashing Competition, has taken over from bcrypt — not only is it fast, it also lets the implementer trade off speed and memory usage with requirements around side-channel and cracking attacks.

But by moving to long, high-entropy passwords that are unique for each system, this created yet another issue: how can users possibly remember all of these passwords?

Password managers

Password managers helped users manage their growing collections of credentials — 168 passwords on average. Available as both standalone apps like 1Password and built directly into platforms like Google Chrome and iOS. Password managers have become mainstream security advice, even superseding VPNs for family recommendations.

Password managers also gave IT teams visibility into password practices for the first time. Organizations could finally enforce password policies and see whether users were following them. But password manager adoption remained inconsistent, and the core problem persisted: too many systems requiring separate credentials.

Enterprise identity federation

Identity federation emerged because organizations hit two walls. Users couldn’t manage dozens of passwords, and IT teams couldn’t track access across multiple systems. Centralized identity management solved both problems: users get one set of credentials to remember, and IT gets a single place to manage access.

Microsoft Active Directory (AD), launched in 1999, was the first real solution to enterprise identity sprawl. Instead of maintaining separate user accounts for every server, printer, and application, IT teams could manage everything from one directory. AD became the “single source of truth” for who had access to what within the corporate network. AD implemented Kerberos as its authentication protocol, including Kerberos’ delegation and impersonation capabilities, which allowed services to act on behalf of users within the enterprise network.

However, AD only worked on the local network. SAML, introduced in 2001, tried to solve this by letting identity providers send authentication statements and attributes across domain boundaries, extending identity beyond solely AD-based systems.

When cloud services emerged in the mid-2000s, identity needed to extend even further. Hosted identity providers like Ping Identity (founded in 2002) and Okta (founded in 2009) were introduced to bridge the gap: to offer a way to federate on-premises identities into cloud SaaS applications. They weren’t replacing AD, but extending it to work with SaaS applications. This was the beginning of modern identity federation.

OAuth, introduced in 2007, brought delegation to web applications and third-party services. Instead of sharing passwords, users could grant specific permissions to external applications. Later, OpenID Connect, standardized in 2014, extended OAuth to handle authentication in addition to authorization. Together, these created a comprehensive identity stack:

• Centralized identity stores (AD, LDAP) for centralized user, group, and access management
• Federation protocols (SAML) to connect across domain boundaries
• Cloud identity providers (Okta, Ping) to extend directories to the cloud
• Authorization frameworks (OAuth) and authentication extensions (OpenID Connect) to authenticate delegated authority

The early 2000s Microsoft ecosystem was the golden age of enterprise identity — everything integrated smoothly, letting you authenticate the same way to your desktop, network, and printer.

Social login

Consumer identity saw similar consolidation. Social login emerged with Facebook Connect (2008) and Sign in with Google (2011), letting users use existing accounts to federate their personal consumer identities, rather than needing to create new accounts for every site they visited.

Social login succeeded because it solved the same problems enterprises were facing: reducing password fatigue while shifting authentication burden to providers with dedicated security teams. The time-consuming and risky processes for password reset and account recovery could instead be handled by providers with significantly more resources and experience.

Multi-factor authentication

Organizations moved from a single password for authentication, to two-factor authentication (2FA), to multi-factor authentication (MFA).

MFA means that just a password isn’t enough — instead, to verify a user, multiple verification types are needed. These are typically described as: “something you know” (like a password), “something you have” (like a device), and “something you are” (using biometrics). The idea is that merely a compromised password alone shouldn’t grant access — attackers would need to compromise multiple factors.

Many kinds of factors have existed over the years:

• RSA SecurID tokens (1980s): The original “something you have”: physical devices on a keychain that generated time-based codes. Effective but expensive and annoying to carry — plus, the batteries died.
• SMS codes (mid-2000s): Convenient, and what is still probably the most widely used second factor today. Though vulnerable to SIM swapping, SMS codes were crucial for making MFA mainstream and accepted. (Plus, they gave us all a legitimate reason to keep our phones within arm’s reach at all times!)
• Authenticator apps (2010s): Google Authenticator (2010), Duo (2010), Authy (2011) improved security with TOTP codes generated on the user’s device.
• Push notifications (mid-2010s): Instead of generating codes, what if those apps instead sent push notifications? Much more convenient, but these caused “notification fatigue” — users would approve notifications without thinking, even when they hadn’t actually tried to log in. This made phishing attacks easier, not harder.
• Hardware security keys (mid-2010s): YubiKeys and other FIDO U2F hardware tokens generate unique codes when touched, providing proof of presence without requiring users to type anything. This allows for much longer codes, improving security without requiring more effort from the user. This became best practice when Google published a case study that showed that implementing hardware keys effectively eliminated successful phishing attacks in their environment.
• Platform authenticators (mid-2010s): TPMs in devices enabled hardware-bound key material. Combined with biometrics like TouchID (2013), Windows Hello (2015), and FaceID (2017), these verify multiple factors: that both the user has the device, and the user is the person they say they are.

The biggest barrier to MFA adoption isn’t technical complexity — it’s that many applications still don’t support MFA. Just like with SSO, you’ll find apps that don’t offer MFA at all, or charge extra for it as an “enterprise” feature.

Passwordless

Passwordless authentication takes MFA to its logical conclusion: eliminating passwords entirely. Instead of adding secure factors to passwords, make the secure factor the only factor.

This first started with magic links (mid-2010s), which allowed for email-based authentication without passwords by sending a user either a link or a code via email. Magic links were especially popular for social logins, where forgetting your password meant that you could still access your account via email. However, these links are phishable, and allow for account takeover if your email is compromised.

The passwordless movement took off as biometrics became possible, then normal, and eventually, mainstream. Device biometrics (mid-2010s) allowed for platform authenticators like TouchID, Windows Hello, and FaceID to auth using a user’s biometrics — but instead of using these for second factors, using these to secure primary factors.

The WebAuthn standard launched in 2019, specifying how to implement FIDO2 for web APIs. By standardizing passwordless authentication for browsers, WebAuthn enabled phishing-resistant credentials across the web.

WebAuthn succeeded because it achieved the seemingly impossible: improving both security and user experience simultaneously. Hardware-bound credentials resist phishing since they’re tied to both physical devices and specific services. When FaceID replaced typing passwords on mobile devices — or entering a 2FA code, or selecting from a password manager — users adopted it because it was faster and easier, not because of its security benefits.

Passkeys

Passkeys were supposed to make WebAuthn mainstream. The rollout has been messy. Apple, Google, and Microsoft promised a better user experience in 2022: biometric-based FIDO credentials that work across platforms and devices. This would also improve security, as these phishing-resistant credentials are bound to specific origins.

Instead, passkeys created vendor lock-in and user confusion. Passkeys have been confusing at best, due to inconsistent experiences across providers. Cross-device syncing only works within ecosystems: Apple devices to Apple devices, and Chrome sessions to Chrome sessions. Users with multiple platforms face competing password managers during every signup or login, uncertainty about where their passkeys are stored, and unclear account recovery processes. And, passkeys still have limited support.

The industry was so excited about WebAuthn and passkeys (rightly so) that we bungled the user experience. Biometric unlocking for password managers and direct passkey authentication compete for attention during the same workflows. Despite being more secure and theoretically easier to use, passkeys aren’t something most of us would recommend to our families. The industry tried to create a better user experience and made things more confusing instead.

That said, passkeys do represent meaningful progress: moving from something users know (passwords) to something users both are and have (devices with biometrics).

Looking forward

The evolution continues beyond just login. Authentication and authorization are blurring together. As authentication becomes more continuous and adaptive, systems now verify both identity and permissions for every action, not just at login. This means usability challenges in authentication increasingly apply to authorization too.

The tension between security and usability that defined authentication’s early history is finally resolving. The best authentication controls — hardware security keys, TouchID, well-implemented SSO — are both more secure and more usable than what they replaced.

This matters for security teams beyond just authentication. Instead of assuming that better security means more user friction, look for solutions that improve both. The security controls that actually work are the ones people want to use.