Adam Smigielski/Getty Images
Over the last few decades, compromised usernames and passwords have typically been at the root of some of the most sensational, damaging, and costly data breaches. An incessant drumbeat of advice about how to choose and use strong passwords and how not to fall prey to social engineering attacks has done little to keep threat actors at bay.
Additional factors of authentication, such as the transmission of one-time passwords or passcodes (OTPs) over SMS or email, are widely regarded as band-aids to a flawed system and are themselves considered to be insecure. In the majority of implementations, neither SMS nor email involves end-to-end encryption, and email is particularly vulnerable to interception through a variety of techniques (one of which, ironically, is compromised passwords). As my colleague Lance Whitney noted in why SMS two factor authentication codes aren't safe, some SMS infrastructure providers can't be trusted to handle authentication-related traffic.
In June of this year, BankInfoSecurity.com reported that the UAE Central Bank "issued a directive asking financial institutions to eliminate weak authentication methods, including SMS and email one-time passwords." In April, an Android-based SMS message interception malware called Gorilla was discovered to be under development (evidence that threat actors have taken an interest in SMS). In anticipation of AI's role as a hacker's weapon of choice, Visa announced in December 2024 that "it will require Australian financial institutions to move away from SMS OTPs as the sole factor for payment authentication to address the threat of AI-driven fraud and scams."
Over the last five years, in response to the need for something entirely different, more secure, and less vulnerable to human ignorance, some of the biggest tech companies -- cooperating as the FIDO Alliance -- have been preparing a new type of passwordless credential designed to replace usernames and passwords. That credential is technically referred to as a FIDO2 credential but is more commonly known as a passkey.
The key difference between a passkey and a password is that, unlike passwords, with passkeys, users never have to share their secret in order to gain access to a secure system. Instead, passkeys rely on public key cryptography in a way that users never have to submit a secret like a password to their websites and apps (collectively referred to as "relying parties"). Here's the big idea behind this approach: If you fall out of the habit of sharing your secret with a legitimate relying party, then you'll never mistakenly offer it to a malicious actor either.
But passkeys have a chicken-and-egg problem. Just because the technology already exists doesn't mean we can just go use it. Before we can do that, all the websites and apps that we use must support passkeys as a form of credential and authentication. While some of the biggest tech companies -- like Apple, Google, and Microsoft (three of the organizations that developed the standard) -- now support passkeys as a credential for signing into their services, most relying parties have yet to catch up.
In this, part 2 of ZDNET's six-part series "How passkeys work," I'll take you through the first step in setting up passkeys: discovering if a relying party even supports them.
Discovering and engaging a relying party's passkey capability
Most of us are familiar with the workflow for establishing a new username and password with a relying party. You visit a website, click a button that says something like "Create an account," and at some point, you're asked to create a username and a password. (These days, relying parties have gotten much better about rejecting weak passwords.) This workflow is essentially a form of credential enrollment where the credentials are your username (often, your email address) and a password.
... continue reading