Passkeys are an alternative to passwords that allow you to sign in to any website or app that supports this technology without needing to define/remember a password.
Over the last couple of years, the tech world has been witnessing many companies updating their products to add support to this new technology, including tech giants like Apple, who introduced several APIs and device features related to passkeys in iOS 16, and Google, who has been pushing passkeys hard since announcing passkeys support for Chrome and Gmail back in 2022.
When I first saw Apple and Google’s announcements, I wasn't sure what I was looking at. The fact that the tech industry has been trying to move away from old-school passwords wasn't news to me, but I asked myself: didn't we already solve this problem when products started allowing users to register a "secondary" authentication requirement, such as receiving an SMS containing a PIN code?
I then decided to look deeper into this topic, and was so pleasantly surprised by what I found that I thought it would be cool to share it with you. In this article, we'll take a look at what passkeys are, why companies like Apple and Google are adding support for them, how they work under the hood, and whether or not you should convert your own accounts to use them and build support for them in your mobile apps!
The problems with passwords and two-factor authentication
In order to understand what passkeys are, we need to first take a step back and understand how authentication evolved over time.
Despite being a core part of the internet since forever, old-school username/password combinations were never really appreciated as a form of authentication. While very straight-forward to set up, passwords are a security nightmare for multiple reasons:
- They can be guessed
- You can be tricked into revealing them
- They can be forgotten
- You need to be careful not to reuse them
- Even if you do nothing wrong on your side, hackers can steal them from the company's servers
Historically, in order to control these flaws, systems in which security was a concern would then request "additional" proof from their users, as a way to minimize the risk that the person trying to log in wasn't who they were claiming to be.
How exactly they did that varied depending on what system we are talking about, and there was no real standard. When I was a kid, I remember that banks would give the consumers "smart cards" filled with a bunch of pin numbers that were specific to your account, which would then be requested by the bank when trying to perform important operations like withdrawing money. The idea was that if you had the right pin, then you must be who you are claiming to be, because the chances of someone guessing not only your bank credentials but also those very specific pins were next to zero.
It's hard to say who invented this concept of "providing additional proof" because this practice always existed in one way or the other, but from a legal perspective, the first patent for one such mechanism was held by AT&T in 1998. Today, this practice is usually referred to as Two-Factor Authentication (2FA), and it first became widespread when mainstream internet companies like Google started allowing users to use phone numbers/SMS as a form of 2FA in the early 2000s.
But while 2FA greatly improved the internet security situation, it didn't necessarily solve it because it also has downsides of its own:
- There's no agreed upon "standard" on how to do 2FA. Some systems use SMS, some use one-time tokens, some use their own proprietary mechanism, and some let you choose between several options.
- You need to do multiple things before actually signing in, so it has some friction attached to it.
- The more secure 2FA mechanisms are not very straightforward to set up and use, which means they are out of reach for people who are not tech-savvy.
- 2FA is usually attached to a physical device, meaning losing a device can mean also losing access to your account. (Certain mechanisms have "recovery codes" that you can use in such cases, but they also provide yet another avenue for your account to be stolen.)
- It doesn't solve the problem of phishing, because you could still be tricked into revealing your 2FA codes.
To make things worse, certain forms of 2FA that were once trusted by users turned out to have vulnerabilities uncovered by hackers, making them not safe anymore. The most notable example of this is SMS, which turned out to be vulnerable to SIM-swapping attacks and even simple social engineering tricks such as calling the phone company and saying that you "lost" your SIM card, as a way of tricking the operator into giving you access to someone else's messages.
WebAuthn: How the idea for passkeys came about
In order to address the flaws of old-school passwords and 2FA, a group of companies including PayPal and Lenovo founded the FIDO Alliance (which stands for "Fast Identity Online") in 2012 with the goal of developing new authentication protocols that were safer, more user-friendly, and most importantly, provided an open standard that would enable such protocols to be used interchangeably across different devices and systems. Today, the alliance has grown to include a wide variety of companies, with tech giants such as Apple, Google, and Amazon now within its ranks.
In 2016, four years after its inception, the alliance created alongside the World Wide Web Consortium (W3C, a.k.a. the folks that make big decisions about how the web should work) a first public draft for an open standard that could fulfill their vision: Web Authentication, or WebAuthn for short.
WebAuthn defines a set of APIs that allows users to authenticate themselves without passwords or 2FA, using instead a pair of asymmetric encryption keys as a way to provide proof. The idea behind it is that by having a server hold the public key of the pair and the user the private one, the server should be able to have proof of who users are claiming to be by asking these users to "sign" a small message with their private key. If the server is able to decrypt the message with the claimed user's public key, then the user must be who they are claiming to be.
Sidenote: If you have no idea what any of that just meant, I recommend that you pause this article and first read our article about how code signing works for a detailed explanation of what asymmetric encryption is and how it's used for modern internet security!
In other words, you do have a "password", but not one in the traditional sense. The vision behind it is that whatever system is implementing WebAuthn would take additional steps to hide this from the user by automatically generating and managing keys on their behalf, thus giving the impression that you are truly passwordless.
This authentication standard has enormous benefits over traditional passwords and 2FA:
- Because WebAuthn abstracts the "signing" process, attackers cannot trick you into giving away your private key. They also cannot be guessed (unless you have seven quintillion years to spare), and you do not have to worry about them being reused because you'll have a different key for each website or system that you use.
- Because WebAuthn is designed so that your private key never leaves your device, attackers cannot steal this information by attacking servers anymore. The server has no idea what your real credentials are, it just knows how to confirm them.
- While the technical details of how WebAuthn works are as complicated as it gets, those details are meant to be abstracted by your devices, meaning using WebAuthn is as simple as tapping a button.
Another notable feature of WebAuthn is how it handles the scenario in which you might be trying to login to something from a different device than the one that is actually storing the private key. If you use password managers like me, then you have probably bumped into this situation: If the device in question isn't also logged in to your password manager, then you have no easy and secure way to get your password over to the other device other than to type it letter by letter, which can be very annoying since password managers usually generate extremely complicated passwords.
WebAuthn, however, doesn't have this problem! The standard defines APIs for how to use QR codes and Bluetooth to authenticate yourself using someone else's private key, which is meant to solve this exact scenario of "needing to login from a different device".
This may sound extremely unsafe, but it's actually not, as 1) you don't send the "real" private key, but rather a one-time-use fake key, and 2) the system is designed so that this only works if the devices are in close proximity of each other, meaning you cannot trick someone on the other side of the world into accepting a request to share their key.
Lastly but not least, since WebAuthn was designed as an open standard, you can use it across different devices as long as everyone is "respecting" the standard. You don't need to have multiple "authenticator apps" like you used to need in the early 2FA days; as long as you have anything that supports the WebAuthn standard, you can use it to "speak" to any website (or other device) that also supports it. For example, you could have an iPhone share a private key with an Android phone using the feature mentioned just above, and vice-versa.
In 2019, W3C bumped the WebAuthn proposal's status to Recommended, thus opening the floodgates for everyone interested to start considering officially supporting it (though, as we'll see further down, not many websites/apps do so as of writing)
WebAuthn and passkeys
That's cool, Bruno. But what does this have to do with passkeys?
You see, "passkeys" and WebAuthn's private keys are the same thing; the former is simply a more user-friendly name that the industry chose to use when referring to them. So when a product announces that they "added support for passkeys", what they mean is that they've added support for WebAuthn. Products like phones / password managers / hardware keys, which are called authenticators in WebAuthn's terminology, implement the client-side bits relating to generating/storing/sharing passkeys, while products like apps / websites, which are called Relying Parties (RPs), implement the server-side bits relating to account creation and the process of requesting/validating information coming from an authenticator.
As of this writing, the number of apps / websites that support passkeys is relatively low (you can find a full list here), but it contains many of the major players such as Apple, Google, Amazon, and X. When it comes to authenticators (the products that can generate/store passkeys), besides iOS and Android, you'll find that many popular password managers like 1Password now have full support for passkeys.
The downsides of passkeys
We talked a lot about why passkeys can be better than using passwords and/or 2FA, but it would be very naive of me to claim that you should abandon everything in favor of it.
One of the most common complaints about passkeys, and one that we can’t not mention, is how it makes you dependent on your device. If you lose your device, you better have been syncing those passkeys with another device that you have easy access to, because otherwise you will have effectively locked yourself out of your accounts. In other words, the exact same problem we already had with certain forms of 2FA.
Here in Sweden, you have a digital ID that lives in your phone, and most services require you to authenticate yourself via this ID. I must say it's not a good feeling, because if I lose my device, I essentially lose my entire identity. Passkeys have this same danger attached to them, and it's something you must consider before changing all of your accounts to use them.
Another downside to consider is that while WebAuthn itself has maximum security in mind, there's nothing preventing companies like Apple from messing up and introducing a security flaw somewhere. Thus, the security of passkeys is only as good as the security of the specific implementation you're using, meaning any claims that passkeys are universally secure/safe must be taken with a grain of salt.
Conclusion
As a developer, passkeys amaze me and I have been happily using them in the few websites/apps that allow me to as of this writing. At the same time, they have big enough downsides that I have a hard time convincing myself that they actually "solve" the password problem. Perhaps one good way of looking at them is not as an universal replacement for passwords/2FA, but rather as an alternative you can use in cases you think it makes sense when considering its pros and cons.
If you'd like to try out passkeys today, here are some links to a couple of guides from different companies on how to get started. The process of creating a passkey and attaching it to a particular account is exactly the same regardless of which authenticator you're using; the only difference is what you're using to start the process. Different authenticators offer slightly different features (Apple devices, for example, sync your passkeys via iCloud), so it can be nice to check what options you have before committing to one of them!
- Apple's guide on how to use your iPhone/Mac as an authenticator
- 1Password's guide on how to use 1Password as an authenticator
- Google's guide on how to add a passkey to your Google accounts / how to use your Android device as an authenticator
