Credit: Dreamstime
Passwords are a central aspect of security infrastructure and practice, but they are also a principal weakness involved in 81 per cent of all hacking breaches.
Inherent useability problems make passwords difficult for users to manage safely. These security and useability shortcomings have driven the search for alternative approaches known generally as passwordless authentication.
Passkeys are a kind of passwordless authentication that is seeing increasing focus and adoption. They are set to become a key part of security in the coming years.
Passkeys represent a more secure foundation for enterprise security. Although they are not foolproof (they can be synced to a device running an insecure OS, for example), they are far more secure than passwords for customers, employees, and partners alike.
Passkeys versus passwords
The root security problem with passwords is that they are just strings of characters that unlock secured resources without consideration as to who owns them. It’s like a metal car key that unlocks and starts the car without regard to any other factors. The statistics on password credentials available to criminals are alarming and growing worse by the year.
Passkeys are an approach to authentication that is multi-factor, with an emphasis on the device as a first factor. By uniting the device with another factor, passkeys evolve past the “what you know” style of security represented by passwords to a “what you possess and what you know”.
As Matias Woloski, CTO and co-founder at Auth0, says, “As passwords get replaced, the phone will represent a stronger first factor. This will not only improve the user experience but security as well.” Passkeys are not limited to smartphones and are available on other devices such as tablets, laptops, and PCs.
Woloski points out that Apple, Google, and Microsoft all support passkeys. This is an indication of the tidal force behind passkey adoption, but also reveals something about how passkeys work.
Newer passkeys include a cloud-storage portion for syncing between devices and in that aspect the provider you use (e.g., Apple for iCloud) influences how the passkeys will behave. Passkeys can smoothly transition among devices within the same ecosystem and work is underway to simplify cross-ecosystem transfers.
How passkeys work
The strength of the device factor is simple: it’s a physical entity. A hacker in Russia can’t steal an employee’s phone in California. Of course, a phone can be stolen or misplaced, but it is (almost certainly) already locked down and passkeys use the phone along with a second factor.
The phone (or other device) is already an entity with which employees interact regularly, are accustomed to treating securely, and keep at hand. It is also associated with other verifiable information (like a phone provider account).
Although the physical device is the anchor to passkey security, it’s not an actual hardware component that associates the passkey with the device. Instead, it’s a bridge between the device and the user applications mediated by the OS or browser. A lot of work has gone into (and continues to go into) orchestrating this securely.
The FIDO alliance is the main body behind the definition of specs around passkeys, and all the big cloud service providers (CSPs) and passkey infrastructure providers are members. Along with the W3C, FIDO has introduced the WebAuthn API for standardising how passkeys work and providing libraries to use on both the front end and the back end.
Types of passkeys
The physical device features make for a stronger baseline security. Atop this factor are several secondary factors that are used to verify the user is the valid owner of the device. The most prominent types of passkeys are biometric (e.g., fingerprint or facial recognition), token-based, PIN-based, movement-oriented, or even passwords.
How passkeys use public key cryptography
These factors (device and secondary factor) are used by the passkey service on your device to create an asymmetric cryptographic key pair for every website, app, or service (the authenticating app) that you use passkey authentication on.
The private key is stored on the device in a key vault, and the authenticating app holds the public key. This arrangement has many systemic security strengths over passwords. Since only the public key is exposed, for instance, there is no useful target for hackers on the wire or in databases. The public key is useless to attackers.
How the end user uses passkeys
This video from Google shows a screen capture of a passkey login interaction. The bottom line is that creating an account and logging in with a passkey is simpler than a password. The passkey is established on the device for the website with a fingerprint swipe, face scan, or other second factor.
This is where a password could theoretically be used as a secondary factor to validate that the current user is the real user. Thereafter, the user would not have to enter the password on subsequent logins. The password or other factor is never broadcast or stored remotely.
Multi-device passkeys
The latest in FIDO passkeys specs are multi-device. Once a passkey is established for a given service, the same device can be used to securely share it with another device. The devices must be in close proximity, within range of wirelessly connecting, and the user takes an active role in verifying the device sync. The remote cloud service for the given device also plays a role.
That means that an iPhone uses Apple's cloud, an Android device uses Google Cloud Platform (GCP), and Windows uses Microsoft Azure. Efforts are underway to make sharing passkeys across providers simpler. It's a rather manual process to share across providers, for example, to go from an Android device to a MacOS laptop.
Passkey benefits and drawbacks
Passkeys are cryptographic keys, so gone is the possibility of weak passwords. They do not share vulnerable information, so many password attack vectors are eliminated.
Passkeys are resistant to phishing and other social engineering attacks: the passkey infrastructure itself negotiates the verification process and isn’t fooled by a good fake website -- no more accidentally typing a password into the wrong form.
There are some enterprise security concerns, in particular ensuring employees and others follow policy for the security of devices used with passkeys.
Beyond that, there is ongoing work around passkey recovery. It would be nice to be able to recover all your passkeys from the cloud provider backing them in one go if a device is lost, stolen, or destroyed. The process requires re-requesting a passkey from each service. On the plus side, a stolen device is not a security vulnerability as the device itself must be unlocked to gain access to the passkey.
Implementing passkeys
Passkeys are an important development that enterprise IT leaders should be thinking about in terms of how they can improve user experience and safety and how to introduce them into their processes and infrastructure.
Fortunately, they are not that difficult to add as most of the heavy lifting is handled by well-defined libraries and specs developed by the big-tech-backed open consortium FIDO alliance. Moreover, third-party security services are moving to support passkeys and make it that much easier to leverage them.
The biggest remaining element in the passkey infrastructure is for applications and sites to begin using them. Only a handful of websites have implemented passkey authentication. That situation is likely to change quickly.
For those in charge of cybersecurity for software projects, the advent of passkeys represents both an onus and an opportunity. Building out the support for passkeys will require an effort in proportion to the scale of the existing infrastructure. Fortunately, third-party security tools and providers are moving to support passkeys, and this can greatly simplify the process of incorporating them.
Adding passkey authenticator support to an application implies modifying the front-end and back-end components to support standard authentication workflows like account creation, revocation, and log-in. There is also the specialised use case of converting from a password-based account to a passkey-based one.
The WebAuthn API
In the browser, the WebAuthn API can be used as the standard mechanism for bridging between app code and passkey support. The WebAuthn API allows the developer to generate a new passkey (that is, support a “Create Passkey” feature) on the front end. Remember: the private key never leaves the user device.
The passkey creation process will require info from the backend server (like user.id and a challenge field that is used later during authentication), the data that will tie the specific app, user, and passkey together. Once created, the front end sends the public key to the server for storage and future authentication.
Most browsers support WebAuthn now. Beyond that, the device itself must support a platform-based passkey authenticator. That includes most devices these days. Browsers’ WebAuthn API now includes a conditional flag for easily checking if it’s available to the user.
From a nuts-and-bolts perspective, supporting passkeys means incorporating JavaScript code to handle the authentication interaction, a small amount of UI, and the backend API to respond to the requests and persist the data.
It’s possible to directly use the WebAuthn server-side libraries to process the requests on the backend but using open source libraries can simplify that.
