I must be dense. I just don’t see how that’s an improvement.
Admittedly my primary experience is with the code kiddies at my campus trying to implement Duo through a dozen redirects to Google, Microsoft, and whichever vendor platform we’re trying to login to. It’s a hot mess.
Your passkey is an encrypted message that authenticates you, the service you’re trying to reach, and your computer.
If you go to a phishing site, the passkey won’t even come up because the browser doesn’t recognize the site. Granted a dumb user could still use their user/pass but ideally the user has MFA set up so they can’t get far.
The goal of a passkey is to replace username and passwords entirely so that phishing becomes less common.
The main issue with passkeys is that unless you have something like a YubiKey or an authenticator (like bitwarden), the passkey is tied to the browser which means if the device gets lost you can’t log in anymore.
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.
How do you authenticate your passkey?
Either with a pin or thumbprint
I must be dense. I just don’t see how that’s an improvement.
Admittedly my primary experience is with the code kiddies at my campus trying to implement Duo through a dozen redirects to Google, Microsoft, and whichever vendor platform we’re trying to login to. It’s a hot mess.
Your passkey is an encrypted message that authenticates you, the service you’re trying to reach, and your computer.
If you go to a phishing site, the passkey won’t even come up because the browser doesn’t recognize the site. Granted a dumb user could still use their user/pass but ideally the user has MFA set up so they can’t get far.
The goal of a passkey is to replace username and passwords entirely so that phishing becomes less common.
The main issue with passkeys is that unless you have something like a YubiKey or an authenticator (like bitwarden), the passkey is tied to the browser which means if the device gets lost you can’t log in anymore.
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.