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
A passkey is generated by a cryptographic program and while nothing is uncrackable, it’s very very very complex to crack.
It’s the equivalent of smashing your keyboard including special characters and caps 50 times instead of, per your example, ‘CatsRule123’ which is exceptionally easy to crack.
It’s like when google suggests a password to you, but the password is something like ‘Cx3t-RwsHXhso5gnt’ (I literally just pushed random keys)
Following this as I thought a passkey was a temporary thing like 2fa and I’m clearly wrong.
You know how you can sign into phones using your face or fingerprint. Well say you want to login to a website with a passkey. If you have generated that passkey using your phone-appropriate provider (think Google, or apple) then the website will ask you to use your fingerprint or face on your phone’s to log you in to the website, just like you use to unlock the phone itself.
This is secure as they need to have access to your phone at the moment of accessing the website, as well as access to you… Face or fingerprint.
So this does away with passwords that you have to remember and instead uses a key, which in my example above is the combination of phone and biometrics.
It does not have to be phone, it can be a Windows hello sign in (pin, face, etc) or a dedicated physical token, but the point is no more remembering passwords, you create passkeys tied to a device and requiring you to provide an easier input than a password, typically something biometric, but can in fact be other things.
A passkey, unlike a password, uses a trusted device to verify your identity and grant you access to the account you’re trying to access. This eliminates the need to have passwords.
This is achieved through cryptographically generated public and private key. The private key is stored on the trusted device – like your phone – which is protected by whatever means you use to unlock your phone (face, fingerprint, passcode, etc.) The public key is shared with the app or website you have an account for.
When you want to sign in, your device will prompt you to verify your identity using your device – which is only accessible through your biometrics or passcode. Then your private key and the public key are used to generate an authentication that tell the company you are who you say you are which allows you to log in. This is the same process by which ubikey and other physical authentication devices work (as far as I know), but eliminates the need of carrying a second device in addition to your phone.
You can also check out this thread for a more fleshed out (but still digestible) explanation:
Note: This is not the same as multi-factor authentication (MFA) which is a (normally) 6 digit code sent to your device to act as a secondary layer of authentication to your password. MFA are generally considered unsecure and easily obtained by bad actors through social engineering.
So with passwords, your password is your “key” to your account.
Imagine that you are not typing in a password, but having your phone physically with you is the key to your account. What that means in the login process? Let’s say you want to sign into gmail. You type in your email address, press next, then your browser, for example Chrome will present you a QR code. You scan this with your phone, use biometric authentication on your phone, and boom, you’re in. You don’t have to type in anything else. That’s how your phone is your key.
On the technical side, your phone and the computer you are using has to be close to each other, because this works through Bluetooth and / or Wi-Fi. So you can’t sign in through a picture. The passkey itself will be presented by your phone to the computer digitally on the network. That passkey is cryptographic and generated, and a pretty long random character line. Instead of you having to type in this very long unlegible string, your phone “sends it to the computer” virtually.
Safer, because longer and more random than a password, and, in its own way, works only when you are around.
I’ve seen OP confused by a couple of replies so I’m going to give it my go:
I’d like to send you a HUGE amount of money, but I want to be insanely sure that it’s actually you and not an imposter. An easy way would be to meet up and hand over the money, but I’ve never met OP before and I don’t know what they look like. All an imposter would have to do is know OP’s username and id give them the money, I have no way to verify it’s them otherwise.
Well, what about a secret code word? I know OP’s name, so when I meet up with them I can not only verify their name (publicly available to anyone), but also the secret code word we came up with via private message. That’s waaaay better, but someone could still find those messages, read them, and walk away with the money.
So now what? Well, what if we placed our trust in an irrefutable database – like ID cards? What if I was able to go to the government before we’ve ever met and get copies of OP’s driver’s license and vehicle registration? When they pull up, I can just look at all of the details of the car they pull up in, and see the details on the driver’s license to see if it matches up to the person that gets out. That way, I can be super sure it’s you without even asking you a question and the money is definitely going to the right person.
The way this translates to this situation is that the first paragraph has no protection, the second is a password, and the third is passkeys. Passkeys are different from passwords because trust is established BEFORE the sign in process – the site you’re trying to sign in to registers with your phone during initial setup or rollout of passkeys. Once the trust is established initially, all the devices need to do is talk to each other to confirm your identity, no need for you (or an imposter) to screw up and misidentify you with an insecure password or loose lips 2FA code.
A passkey is more cryptographically secure (by a lot), and unphishable because it cryptographically verifies the domain instead of relying on the user to notice if the URL is one character off. It’s encrypted locally and you only have to remember one pin, or have one biometric, for all the passkeys on your device (rather than managing hundreds of passwords). You can keep passkeys for all your accounts on one device, and you can register multiple passkeys per account so you can have a backup device or security key.
It’s a part of the FIDO2 protocol, so I would have said it’s always 2-factor (you know your pin or are your biometric and have your phone or security key) but now Google and Apple are both syncing passkeys so it becomes possible to break that and get access to a passkey with only things you know.
Let’s say I have an extremely tall treehouse, one where I can’t see who is visiting, but it requires a secret to enter.
We decide instead of passwords, we’re going to do something different. Since anyone can discover your password, we’re going to exchange information in a way to make sure it’s actually you.
So let’s say when you want to come in, I’ll tell you a secret word, and then you’ll take a video of you saying your password and the secret word and send it back to me. Now I’m using at least two factors to determine that this is you, and that you’re actually asking to come up right now.
This is essentially what passkeys are attempting to do, except instead of a video, it’s something you have, like your cellphone.
When you visit a website, they’ll send your device a challenge. The device is allowed to do whatever to make sure it’s you, and once confirmed, takes a secret it has previously established along with the challenge and makes a result. That’s sent back to the website, and as long as it’s what the site expects, you can get in.
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