The main advantage comes with phishing resistance. Standard MFA (time based codes) is not phishing resistant. Users can be social engineered into giving up a password and MFA token. Other MFA types, such as pop up notifications, are susceptible to MFA fatigue. Similar to YubiKeys, Passkeys implement a phishing resistant MFA by storing an encryption key, along with requiring a biometric. The benefit here is that these are far easier for the average user, and the user does not need to carry a physical device. Sure, fingerprints could possibly be grabbed with physical presence, but there is far less risk that a users fingerprint is stolen, than a user being social engineered over the phone into giving creds. For most organizations and users, this is far more secure.
Standard MFA (time based codes) is not phishing resistant. Users can be social engineered into giving up a password and MFA token.
So basically this is just idiot-proofing the system. If you aren’t the type of person to give your password or MFA token to another person, then passkeys don’t really make better security.
Don’t chalk it up to idiots. The quote mentions “MFA fatigue”, which is something that definitely happens.
If you’re a Windows user (and moreso if you play games on your computer), you certainly regularly have admin prompts. I’m pretty sure that, like everyone else, you just click OK without a second thought. That’s fatigue. Those prompts exist for a security reason, yet there are so many of them that they don’t register anymore and have lost all their meaning.
For my job, I often have to login into MS Azure, and there are days where I have to enter my MFA 3 or 4 times in a row. I expect it, so I don’t really look at the prompt anymore. I just enter the token to be done with it asap; that’s a security risk
It also doesn’t take into account the technological advances that scammers are using more and more. Get a phone call from your boss requesting something sensitive? How sure are you that it really is your boss and not an AI generated voice relying on data from LinkedIn, Facebook, etc. run through a ChatGPT style system to respond to all manner of small talk etc?
It also allows you to login without someone visually observing your password while typing it on a keyboard or on an untrusted device that could have a keylogger.
You can still keep password + 2FA on GitHub and Google Suite (probably anything else that’s currently implementing them), it’s just a convenience/anti-phishing feature right now.
The passkey is synced between devices if it’s kept in a password manager, I haven’t looked at the mechanism that Apple uses to sync it/use it if you store it in the system keychain. I guess you could also have multiple passkeys configured for a few devices.
IIUC Apple syncs them using the most secure way they can, i.e. when you enroll a new device to your account the existing device, the existing device’s HSM encrypts keys using the pubkey of the new one’s HSM; and for recovery from being left with 0 Apple devices there might be (?) an escrow option that’s optional (?)
Cool. I should check it out. I tend to assume that when Apple (or Google) rolled this out that it’s not broken in any obvious way that I would recognize right away.
But like contactless payments, which I’ve advocated my friends and family switch to, I should read up on why it’s more secure.
You don’t have to store them with Google. Passkeys are supported in both iOS and Android natively. Within the last few months both Bitwarden and 1Password support storing passkeys as well.
It does not. The fingerprint always only unlocks the device’s HSM (“secure enclave” in Apple speak).
Between your devices enrolled in the ecosystem, private keys are synced securely (AFAIK, they make it so that an existing device’s HSM encrypts keys using the pubkey of the new one’s HSM); for signing up using your device on someone else’s computer there’s a process that combines QR codes with Bluetooth communication.
At some point, passkeys will be ubiquitous enough they’ll be like low friction SSH keys for web authentication (i.e. there will be no shared secrets in the login process).
It has its own pros.
The biggest one is that it uses asymmetric cryptography. This means that the only one that can sign a challenge given by the server is the one that has the private key equivalent of the public key the challenge was used to be encrypted with.
The challenge is sent to the client, in which the client signs the challenge the server sent with their private key and then sent back to the server. Since the server has the public key, the server can verify whether the signature is indeed from the private key owner. This is possible because the private and public key are mathematically linked. This is the reason why it is phish proof. Though I am not sure whether a phisher can just take the challenge, let the victim sign it and then give back the challenge to login. Can anyone confirm that?
They are not better than hardware keys (since they are basically software versions of physical hardware keys), but at least better than passwords.
That is not technically correct. Passkey is a protocol first and foremost, and the way it is implemented is up to the vendor. Can be software, eg. Apple, Google, Bitwarden, etc, but you can as well use a hardware key, eg. Yubikey has Passkey support for quite a while now.
The reason why I said that is because they are currently only stored in the cloud. It’s not like hardware and passkeys function differently. It’s just that a physical key (that you have) is more secure than having it on some companies computers.
Can someone tell me why I should care about this rather than just continuing to use my password and 2FA?
I’m stealing this from another comment:
The main advantage comes with phishing resistance. Standard MFA (time based codes) is not phishing resistant. Users can be social engineered into giving up a password and MFA token. Other MFA types, such as pop up notifications, are susceptible to MFA fatigue. Similar to YubiKeys, Passkeys implement a phishing resistant MFA by storing an encryption key, along with requiring a biometric. The benefit here is that these are far easier for the average user, and the user does not need to carry a physical device. Sure, fingerprints could possibly be grabbed with physical presence, but there is far less risk that a users fingerprint is stolen, than a user being social engineered over the phone into giving creds. For most organizations and users, this is far more secure.
So basically this is just idiot-proofing the system. If you aren’t the type of person to give your password or MFA token to another person, then passkeys don’t really make better security.
Don’t chalk it up to idiots. The quote mentions “MFA fatigue”, which is something that definitely happens.
If you’re a Windows user (and moreso if you play games on your computer), you certainly regularly have admin prompts. I’m pretty sure that, like everyone else, you just click OK without a second thought. That’s fatigue. Those prompts exist for a security reason, yet there are so many of them that they don’t register anymore and have lost all their meaning.
For my job, I often have to login into MS Azure, and there are days where I have to enter my MFA 3 or 4 times in a row. I expect it, so I don’t really look at the prompt anymore. I just enter the token to be done with it asap; that’s a security risk
It also doesn’t take into account the technological advances that scammers are using more and more. Get a phone call from your boss requesting something sensitive? How sure are you that it really is your boss and not an AI generated voice relying on data from LinkedIn, Facebook, etc. run through a ChatGPT style system to respond to all manner of small talk etc?
It also allows you to login without someone visually observing your password while typing it on a keyboard or on an untrusted device that could have a keylogger.
And, they are actually more convenient because then entire login process is one step, rather than two.
What’s the backup login mechanism when you lose your biometric sensor? How do you pair with the new sensor?
You can still keep password + 2FA on GitHub and Google Suite (probably anything else that’s currently implementing them), it’s just a convenience/anti-phishing feature right now.
The passkey is synced between devices if it’s kept in a password manager, I haven’t looked at the mechanism that Apple uses to sync it/use it if you store it in the system keychain. I guess you could also have multiple passkeys configured for a few devices.
IIUC Apple syncs them using the most secure way they can, i.e. when you enroll a new device to your account the existing device, the existing device’s HSM encrypts keys using the pubkey of the new one’s HSM; and for recovery from being left with 0 Apple devices there might be (?) an escrow option that’s optional (?)
Cool. I should check it out. I tend to assume that when Apple (or Google) rolled this out that it’s not broken in any obvious way that I would recognize right away.
But like contactless payments, which I’ve advocated my friends and family switch to, I should read up on why it’s more secure.
I kind of don’t like to store my fingerprints with Google. Even FBI collects them when you are indicted.
What about allowing us to log in to services via asymmetric keys?
You don’t have to store them with Google. Passkeys are supported in both iOS and Android natively. Within the last few months both Bitwarden and 1Password support storing passkeys as well.
Note that you pretty much can’t store them with Google or Apple; smartphone biometric sensors operate the on-device HSM, not something remote.
So, how does it work when you are accessing account from a different device? How the other device knows your fingerprint?
It does not. The fingerprint always only unlocks the device’s HSM (“secure enclave” in Apple speak).
Between your devices enrolled in the ecosystem, private keys are synced securely (AFAIK, they make it so that an existing device’s HSM encrypts keys using the pubkey of the new one’s HSM); for signing up using your device on someone else’s computer there’s a process that combines QR codes with Bluetooth communication.
It is just an asymmetric key. Phones try to store them securely but you could use an app to just generate them and store your key wherever.
From just now reading the Docs regarding passkeys.
The main draw seems to be that it is easy to sign in (just requiring biometrics for example) and mainly a lot more resistant to phishing.
At this point, you probably shouldn’t.
At some point, passkeys will be ubiquitous enough they’ll be like low friction SSH keys for web authentication (i.e. there will be no shared secrets in the login process).
It has its own pros. The biggest one is that it uses asymmetric cryptography. This means that the only one that can sign a challenge given by the server is the one that has the private key equivalent of the public key the challenge was used to be encrypted with. The challenge is sent to the client, in which the client signs the challenge the server sent with their private key and then sent back to the server. Since the server has the public key, the server can verify whether the signature is indeed from the private key owner. This is possible because the private and public key are mathematically linked. This is the reason why it is phish proof. Though I am not sure whether a phisher can just take the challenge, let the victim sign it and then give back the challenge to login. Can anyone confirm that?
That is not technically correct. Passkey is a protocol first and foremost, and the way it is implemented is up to the vendor. Can be software, eg. Apple, Google, Bitwarden, etc, but you can as well use a hardware key, eg. Yubikey has Passkey support for quite a while now.
The reason why I said that is because they are currently only stored in the cloud. It’s not like hardware and passkeys function differently. It’s just that a physical key (that you have) is more secure than having it on some companies computers.