I think of myself as tech savvy but for some reason i either missed the memo on Passkeys, or just misunderstand how the thing works. Im reasonably sure my parents/granparents will start asking me about this stuff soon (as google / other websites push it on them), and id really like to understand it myself first so i can explain it to them as well.
Right now, to login to website/account/etc i just need to know my login (i.e. my email address, or my username) and my password. For example, “FakeDogLover”+”CatsRule123”. How is Passkey different?
In: 1799
I’ve been trying to look through the replies to see what’s been covered, and boy there’s a lot of crap in here. It’s not surprising—ELI5 is not a good forum for asking about novel, technical things. People are guessing.
I think the key thing that makes passkeys different from passwords is what’s actually transferred to the website. The biggest way people get hacked is that a hacker gets their password, by:
* Hacking the website/service and getting their database of passwords;
* Intercepting the user’s password being submitted to log in; or
* Asking the user for it (a.k.a. phishing).
The problem with passwords is that both parties, the user and the service, need to know it and exchange it to authenticate the user.
Passkeys work differently. They use something called *asymmetric encryption*, which is where both parties don’t have to know the whole secret to do authentication. You use asymmetric encryption all the time, but probably haven’t noticed: it’s what powers HTTPS, the green lock that means your connection to a site is secure. Your browser users asymmetric encryption to talk to the server in a way that only the intended server can read it. It’s also used when you create an account on a service tied to your Google or Facebook account.
An asymmetric key has two parts: a public part, and a private part. You can give your public key to anyone—you can even publish it online, which is what sites do for HTTPS. You keep your private key completely private—it’s never shared with anyone else, ever.
How then can you prove you’re you if you don’t show them your private key? At some point prior, you would have shared your public key in a way the other party trusts. For passkeys, that would be at account creation. When it comes time to authenticate, the service gives you a challenge: they give you some data, and challenge you to encrypt it using your private key. (For our purposes here, _encrypt_ just means to produce different data that, when decrypted with the public key, produces the original data.) So they give you some data, a block of random bytes, and you send them back the encrypted bytes. They then decrypt those bytes using your public key, and if it matches what they sent in the challenge, then they believe you’re you.
It’s a probability, because it’s possible someone could have guessed, but password authentication is also a probability because someone could guess your password. The passkey challenge will be longer than most users’ passwords, and the response _much_ harder to guess.
How does this address the ways hackers abuse passwords?
* Hacking the website/service and getting their database of passwords;
* The service only knows your public key, which anyone is allowed to know. It’s only useful to *check* a challenge response; it can’t be used to log in. The hacker *could* try to brute-force the private keys from the public keys, but that’s *much* harder than brute-forcing password hashes—hard enough that we’ve been comfortable openly publishing public keys online for decades.
* Intercepting the user’s password being submitted to log in; or
* The only thing transmitted during authentication are the challenge, and your encrypted response. And the thing is, those are only good for _this_ login attempt. The service will send a random challenge each time, so having your answer to this challenge doesn’t help with the next one.
* Asking the user for it (a.k.a. phishing).
* The passkey approach never shows the user their private key, and for hardware implementations it may not even be possible to see it. If you get a QR code, it will just contain the challenge and where to send the response.
If your private key lives on your phone, it’s kept in secure storage until your phone is unlocked with your PIN or biometrics. (That storage is _also_ implemented with asymmetric encryption—your phone has its own private key implemented in firmware, so no one can access it without taking your phone apart.)
Latest Answers