The average internet user has 240 online accounts—meaning they should have 240 unique passwords to secure those accounts.
For most users… that’s not happening.
Even as you encourage your users to select unique and hard-to-crack passwords, they probably won’t. And it’s hard to blame them. They are keeping track of hundreds of long and obscure passwords!
But luckily, there is a new(ish) technology that can help your users easily authenticate and secure their accounts against hackers: passkeys.
We expect most, if not all, brands to eventually implement passkeys into their authentication process. So, it’s essential to understand how they work, their limitations, and when/how to make the switch.
Looking at authentication today
Today, we use passwords to authenticate, but users need to follow certain rules to make the process secure, such as using a minimum number of characters, never reusing the same password on different services, and avoiding easily obtainable information.
One of the main problems is that the responsibility of creating, remembering, and managing these passwords is all placed on users.
Passwords are also problematic regarding security, allowing attackers to obtain them through phishing or using leaked databases from previous data breaches. Both users and services share a secret that needs protection, requiring additional security layers to prevent attackers from stealing authentication credentials.
Passkeys: a better default
Passkeys authenticate users using the well-established principles of public key cryptography, the same technology and algorithms we use for certificates and secure navigation on the internet.
A passkey consists of a pair of generated keys:
- A private key, securely stored in the user’s issuing device
- A public key, sent to the service for storage as part of the user’s information
The login process only requires unlocking the device, usually using biometrics (e.g., fingerprints). By doing so, the user achieves two authentication factors in one action: something they have (the device with the private key) and something they are (the biometric check).
With passkeys, the user is seamlessly logged into the service without needing passwords or numeric tokens from SMS, email, or authenticator apps.
Internally, the device receives a cryptographic challenge from the server that can only be solved by the owner of the private key. Using the public key, the server can then verify the challenge and authenticate the user.
WebAuthn, the specification used behind passkeys (also called FIDO2 credentials in technical terms), defines the details of registration and authentication using biometrics. This protocol provides strong security guarantees, including:
- Protection against brute-force attacks, because passkeys are strong and never reused
- Phishing resistance, because each passkey is inherently linked to a specific website domain and cannot be used on a different domain
- Server data breaches become ineffective for authentication, because attackers cannot utilize stolen public keys in the same way they exploit passwords today
Downsides to passkeys
Passkeys are relatively new in the ecosystem, and users may be unfamiliar with their benefits. Some users may hesitate to adopt something new, particularly when it involves accounts and security.
The good news is that large companies such as Apple, Google, and Microsoft already support and promote passkeys.
To add support for passkeys, teams will need to implement code in both the clients and the backend, which requires time and money. There are authentication libraries available to assist with implementation, as well as pre-built paid solutions, depending on specific needs. And even though support is growing month by month, several OS and browser combinations still do not detect and provide stored passkeys when required.
Considering that passkeys are changing the way attackers can obtain access to user accounts, it is expected that new attack vectors will arise and best practices will eventually change in a passkey world. It is important to follow up-to-date security research and ensure the way you implement and fallback to other authentication methods is correctly set.
Next steps for product teams
Passkeys are already here, offering a simpler user experience and a stronger security baseline. So now is the perfect time to explore the requirements for providing users with this alternative.
Before jumping in, it is important to define metrics for your current authentication methods and investigate whether the existing solution already allows for adding passkeys or if you need to use a different approach. Then, you can collaborate with your UX team to determine where and how to present users with the passkey option.
Once the experience is defined, your development team can implement the required changes on the client side (apps and websites) and the backend side with a FIDO Server implementation. If you opt for a paid solution, you must follow their integration steps. However, if you prefer to create a custom solution, a valuable resource is passkeys.dev. It provides references for each operating system, up-to-date information on server libraries, and testing tools to confirm the integration is functioning correctly and is FIDO compliant.
After the implementation, you can initiate a rollout process. By comparing metrics and gathering user feedback, you can determine the appropriate timing for expanding passkeys to a larger audience.
Passkeys and passwords will coexist for a while, but we are heading toward a passwordless world. By preparing your products and platforms for the future, you can stay ahead, simplify authentication, and improve user security.
