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.
How passkeys work
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.
Similar to the enrollment of a traditional username and password-based credentials, some relying parties now offer a workflow for enrolling a passkey as a separate credential that, as an alternative to your username and password, can also be used to sign into a website or app.
Also: Best VPN services: The fastest, most secure VPNs for your home, streaming, and travel needs
Today, most relying parties that support passkeys start you off with a traditional credential and then offer you the option of enrolling a passkey as another, more secure way to login. Some relying parties are more aggressive than others in urging you to enroll a passkey.
And then there are those rare forward-thinking relying parties – such as travel site kayak.com – that bypass the traditional credential enrollment step and start you off with a passkey instead. When I recently signed up for Kayak, there was no option to create a username or password.
Stay ahead of security news with Tech Today, delivered to your inbox every morning.
To illustrate a typical passkey journey from discovery to registration to authentication to deletion, I’m going to use shopify.com as my test subject. I’m using a Mac running Chrome with Bitwarden’s password manager extension installed. (My choice to use Bitwarden should not be misinterpreted as an endorsement. However, I am a strong proponent of using a third-party password manager instead of the one built into your browser or operating system.)
If you’re using a different browser, operating system, test subject website, or password manager to reproduce the hands-on parts of this series, you will likely encounter nuanced differences in the user experience. But generally speaking, the passkey journey – as disjointed and confusing as it can be – is pretty much the same from one configuration to the next.
Also: The best password managers: Expert tested
You can use Shopify to experiment with any of the three primary passkey workflows without setting up an e-commerce storefront. Also, keep in mind the following:
- The same journey will involve minor differences on other browsers and operating systems.
- The basic journey is the same on mobile, but there are some differences that I won’t cover.
- My screenshots were taken just before publishing this series, and the user experience may have changed by the time you try it.
Like most replying parties, Shopify starts you off with a traditional username and password. Once you’ve established those traditional credentials and are signed in to shopify.com, you’ll be presented with an opportunity to create a store as shown above.
Once you click on “Manage account” as shown above, you’ll be dropped into Shopify’s account preferences area, where there are two menu choices in the top left corner: General and Security. Like many relying parties, Shopify’s passkey functionality can be found in the Security or Password area. The next step is to click on Security, as shown below.
After opening the Security preferences, you’ll be presented with the option to “Create a passkey” as shown below. As can also be seen from Shopify’s implementation (which differs from the implementations of many other relying parties), Shopify notes that creating a passkey is “recommended,” briefly explains how a passkey can be used “instead of a password,” and offers a link to learn more about passkeys.
Also: 10 passkey survival tips: Prepare for your passwordless future now
Many passkey proponents discuss passkeys as a method to log in with your fingerprint, face recognition, or a PIN, as can be seen in the same screenshot from Shopify. This latter point is not necessarily accurate and remains a point of confusion and contention in the passkey ecosystem (a point that I’ll discuss in greater detail in Part 5 of this series — What really happens during a passwordless login?).
So far, we’ve only found our way to the “Create a Passkey” button, which isn’t always easy to find. In the next installment, I click that button to trigger the actual passkey registration process – or “ceremony” as some experts call it. As you will see, the journey turns into a technological challenge that requires a bit of planning and forethought.
How passkeys work: Overview | Discovery | Selection | Registration | Authentication | Deletion
–>
Source: Robotics - zdnet.com
