I’m going to get technical. A registered passkey is basically your phone or whatever holding a private key and the server holding the public one. When you want to log in, you enter the username on the service, which contacts wherever you registered it, and asks for a verification. Then, the device creates a nonce, which is a random number to be used once (NumberONCE), and a copy of that number encrypted with the private key. Then, the service can unencrypt the piece and check that the value is the same as the unencrypted value. This process is called a digital signature, it’s a way for online processes to verify the sender of whatever.
This way, the server knows that whoever is trying to authenticate is doing it from the authorised device. The difference between sending a signed nonce and a password, is that is someone steals the signed nonce they get nothing, since usually that number gets registered somewhere so it’s not valid again or something, it’s not exactly as explained but the point is that whatever is sent can’t be sent again. Something like a timestamp in milliseconds where it will be obvious that the signature would have expired. If an attacker captures the authentication attempt, with passwords they get the actual password and can the use it again whenever, while with nonces, they can’t.
Iirc, the server sends the device a code and the device must send the signed code back, so the service knows that the one trying to authenticate is the device. No need for passwords.
Now, if you need to authenticate to gain access to that private key, that’s of course an attack vector, so if you want any kind of syncronisation of passkeys, you need to make sure that you don’t need to send a password to get the pkeys. I use bitwarden, and unless I misunderstood, you don’t authenticate against the bitwarden server, when you access your vault they actually give you you the encrypted data, which you then unencrypt with the password locally on the browser. I’ll have to double checknon this because I have a 2fa on that for extra measure butidk how it actually works. My plan for the future is to actually use a yubikey to authenticate against bitwarden, following the same logic explained above, to then gain access to a bigger pool of passkeys. This way, ultimately all access is protected with my physical key which I can connect to most devices I use, and I can, with NFC use the key to authenticate the android bitwarden app, so it should be completely usable.
In any case, passkeys are better than passwords, provided toy don’t store them in a less secure place. As we all know, the security level of a system is the security level of its weakest cog.
I’m going to get technical. A registered passkey is basically your phone or whatever holding a private key and the server holding the public one. When you want to log in, you enter the username on the service, which contacts wherever you registered it, and asks for a verification. Then, the device creates a nonce, which is a random number to be used once (NumberONCE), and a copy of that number encrypted with the private key. Then, the service can unencrypt the piece and check that the value is the same as the unencrypted value. This process is called a digital signature, it’s a way for online processes to verify the sender of whatever.
This way, the server knows that whoever is trying to authenticate is doing it from the authorised device. The difference between sending a signed nonce and a password, is that is someone steals the signed nonce they get nothing, since usually that number gets registered somewhere so it’s not valid again or something, it’s not exactly as explained but the point is that whatever is sent can’t be sent again. Something like a timestamp in milliseconds where it will be obvious that the signature would have expired. If an attacker captures the authentication attempt, with passwords they get the actual password and can the use it again whenever, while with nonces, they can’t.
Iirc, the server sends the device a code and the device must send the signed code back, so the service knows that the one trying to authenticate is the device. No need for passwords.
Now, if you need to authenticate to gain access to that private key, that’s of course an attack vector, so if you want any kind of syncronisation of passkeys, you need to make sure that you don’t need to send a password to get the pkeys. I use bitwarden, and unless I misunderstood, you don’t authenticate against the bitwarden server, when you access your vault they actually give you you the encrypted data, which you then unencrypt with the password locally on the browser. I’ll have to double checknon this because I have a 2fa on that for extra measure butidk how it actually works. My plan for the future is to actually use a yubikey to authenticate against bitwarden, following the same logic explained above, to then gain access to a bigger pool of passkeys. This way, ultimately all access is protected with my physical key which I can connect to most devices I use, and I can, with NFC use the key to authenticate the android bitwarden app, so it should be completely usable.
In any case, passkeys are better than passwords, provided toy don’t store them in a less secure place. As we all know, the security level of a system is the security level of its weakest cog.
Thanks for this. For the first time, an explanation of passkeys makes sense.