Passkeys might really kill passwords
theverge.com
Passkeys: how do they work? No, like, seriously. It’s clear that the industry is increasingly betting on passkeys as a replacement for passwords, a way to use the internet that is both more secure and more user-friendly. But for all that upside, it’s not always clear how we, the normal human users, are supposed to use passkeys. You’re telling me it’s just a thing... that lives on my phone? What if I lose my phone? What if you steal my phone?
You are viewing a single comment
Can somebody help me understand the advantages of passkeys over a password manager? Googling just brings up tons of advertising and obvious self promotion, or ELI5s that totally ignore best passwords practices using managers.
Passkeys work like a public/private key pair you’d use to secure SSH access to a server. You give the website a public key that corresponds to a private key generated on your local device. Unlike a password it’s not feasible to brute force and there’s nothing you have to remember which makes it more convenient for you to use. If a site is hacked and they gain access to the public passkey you use to authenticate, it can’t be used to authenticate anywhere.
It’s not really an alternative to a password manager, because you can use a password manager to generate and sync a single passkey between all your devices. In fact 1Password is a big proponent of passkeys and even maintain a big directory of sites that use passkeys.
Passwords are known (or accessible in a password manager) by the user and the user gives one to a site to prove they are who they say they are. The user can be tricked into giving that password to the wrong site (phishing).The site can also be hacked and have the passwords (or hashes of the passwords leaked), exposing that password to the world (a data breach).
With passkeys, the browser is the one checking that it's talking to the right site before talking by making sure the domain name matches. Passkeys also don't send a secret anywhere but instead use math to sign a message that proves they are the returning user. This security is possible because there is a public key and a private key. The user is the only one with a public key. The authenticity of the message is guaranteed by math by checking it with the public key that the user provided to the site when they registered their passkey. The site doesn't need access to the private key that the user has to verify the message so there's nothing sensitive for the site to leak.
In practical terms, instead of having to have your password manager autofill the username and password and then do some kind of second factor, it just signs a message saying "this is me" and the site logs you in.
So it sounds like basically it's just client certificates?
Basically, but with a separate public/private key pair per login so they aren't able to link your identity between sites or accounts with it and also synced or stored in a password manager so you don't lose them.
Yep! In fact you can still use client certificates in certain passkey/WebAuthN authentication flows. It's more or less how Windows Hello for Business works (although X.509 certificates are only one type of key it supports).
Basically but with better software and better branding.