A passkey is a key pair where you keep the private key and give the public one to the service. Then you can log in by proving you have the private key. Fairly simple in theory. Horribly complex in practice.
Basically, in public key cryptography, you can generate a set of two big numbers that are mathematically related, one called the private key and one called the public key, collectively called a key pair.
Through a lot of fancy math, you, with your private key, can take a number I give you and give me back another number called a signature. I, with your public key, can do even more fancy math to prove that you do, in fact, have the corresponding private key to the public key I have, based on this signature.
If you give me the wrong signature, I can’t trust that you have the private key, and you don’t get authenticated, but if you give me the right signature, I can trust that you’re you, and you get authenticated.
A number of things. The key is stored on and accessed by a separate coprocessor from the CPU, so the CPU doesn’t even know the private key. That takes its own protocol, over i2c, usb, Bluetooth, etc. Then the browser has to coordinate that protocol to communicate with the web protocol from the frontend JS. There’s also the concept of server verification, so it’s a more complicated handshake than just one signature going one way. Then, of course, there’s the inherent complexity of public key cryptography in general, but you only need to worry about that if you’re writing it from scratch with no library.
From a basic web dev perspective, it’s not much more complex than a password, but that’s because the complexity of the protocols is hidden behind the libraries. A password actually isn’t complex, even when you remove the libraries.
(The private key does not have to live in a separate coprocessor, but that’s the most secure method, and the one covered by the protocol.)
Yes, kind of. You’re still giving them your password every time you log in. And it’s on them whether they store it hashed or in plain text. With a passkey, you know that even if they’re hacked, they’ll never get your actual private key.
But, if they’re hacked, your key is probably the least of your concerns.
There’s a few differences. One is the length. Another is the randomness. The biggest, though, is that in a passkey, the server is verified as well. That means phishing is nearly impossible.
A passkey is a key pair where you keep the private key and give the public one to the service. Then you can log in by proving you have the private key. Fairly simple in theory. Horribly complex in practice.
And what is a private key? How exactly do you “keep” it across multiple devices? It’s all still black magic to me.
Basically, in public key cryptography, you can generate a set of two big numbers that are mathematically related, one called the private key and one called the public key, collectively called a key pair.
Through a lot of fancy math, you, with your private key, can take a number I give you and give me back another number called a signature. I, with your public key, can do even more fancy math to prove that you do, in fact, have the corresponding private key to the public key I have, based on this signature.
If you give me the wrong signature, I can’t trust that you have the private key, and you don’t get authenticated, but if you give me the right signature, I can trust that you’re you, and you get authenticated.
Complex how exactly?
Here, these specs are what they’re based on:
https://passkeys.dev/docs/reference/specs/
Right but what about it do you think is complex?
A number of things. The key is stored on and accessed by a separate coprocessor from the CPU, so the CPU doesn’t even know the private key. That takes its own protocol, over i2c, usb, Bluetooth, etc. Then the browser has to coordinate that protocol to communicate with the web protocol from the frontend JS. There’s also the concept of server verification, so it’s a more complicated handshake than just one signature going one way. Then, of course, there’s the inherent complexity of public key cryptography in general, but you only need to worry about that if you’re writing it from scratch with no library.
From a basic web dev perspective, it’s not much more complex than a password, but that’s because the complexity of the protocols is hidden behind the libraries. A password actually isn’t complex, even when you remove the libraries.
(The private key does not have to live in a separate coprocessor, but that’s the most secure method, and the one covered by the protocol.)
Doesn’t a normal modern password, hashed, essentielly do the same thing?
No sane service has your actual password.
Granted this was 1999 but I wish I could unsee the shit I saw one day when I did a SELECT password FROM user
No. When you log into a website your password is sent to the server. A passkey is not.
That depends entirely on the service.
Nothing prevents the password from being hashed client-side, only ever sending the hash to the service.
Then that hash is effectively your password
True, but with passkeys they’re never sent, by design.
Yes, kind of. You’re still giving them your password every time you log in. And it’s on them whether they store it hashed or in plain text. With a passkey, you know that even if they’re hacked, they’ll never get your actual private key.
But, if they’re hacked, your key is probably the least of your concerns.
There’s a few differences. One is the length. Another is the randomness. The biggest, though, is that in a passkey, the server is verified as well. That means phishing is nearly impossible.