4 ms·

Also now your Windows Hello PIN and your screen unlock PIN on Android will be your master password to all websites. That's a huge new risk for real people. On W

Also now your Windows Hello PIN and your screen unlock PIN on Android will be your master password to all websites. That's a huge new risk for real people. On Windows they don't even bother making a password option which could at least imply that a longer PIN is possible. Windows also asks for the same everytime which strongly encourages making it short. Although I suppose nobody cares because isn't your PIN already your master password on Android/iPhones for your appstore and payments... In short I don't think PINs should be allowed for use with webauthn and these devices should have a very user friendly configurable timeout so that users don't have to enter it nonstop. If I logged into my bank 5 seconds ago, maybe it's okay for me to also log into my second bank without prompting for my master password aka PIN again.

WorldMaker 3y ago
The PINs protect a hardware enclave full of cryptographic keys. The PIN never leaves the hardware device it was input into. (It's an equivalent to the button on a Yubikey or something of that nature and there is a reason that PINs are lumped into the same settings as biometric unlocks like Touch ID and Face ID.) It's an intelligent trade-off, of course, in threat models that involve access to the physical device for threat models that involve remote access of websites and other resources. Yes, if everything uses the same PIN on a device then that adds to the risk of someone snooping your PIN, stealing your device, and accessing many things in the process. If that is the threat model that most concerns you, then yes, this makes things worse. But PINs can't be used remotely at all and never transfer across a wire. They can't be brute forced remotely over the internet. Having someone's PIN but not the specific device that the PIN unlocks doesn't unlock anything (because you still don't have access to any of the private keys on the device without the device). Websites only know your device's public keys. If you use entirely WebAuthn, breached websites only leak public keys. If your threat model involves concerns about internet hackers or the daily breaches we see in services like haveibeenpwned, device-specific PINs are a massive improvement.
- Nathanba 3y ago
  Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. I think webauthn could be great for 2fa without phones. But there are important things missing. For example the google authenticator app has an established way to backup and sync now. There is no such manual backup and sync possibility for Windows Hello passkeys. It's all a bit new now. I suppose as a website owner I would have to let people register multiple passkeys and then the user only has to have one of them to successfully log in. Hm it might be okay. And of course Chrome already added sync support for their passkeys but you can't rely on everyone using Chrome.
  - WorldMaker 3y ago
    > Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. The thing to keep in mind is that the remote threats are bigger and more common, and the "local theft" scenarios fewer and impacting fewer people. Obviously, it is terrifying as an individual user when a device is stolen with enough PIN information. But on the other hand, you can't so easily automate stealing devices physically from people. It is much harder to steal things to anything like the same degree of mass stealing credentials in remote attacks and database breaches. For most ordinary users, they are much more at risk of remote attack or remote phishing than local theft. Device PINs are probably the right balance for the average user's threat model. (If you have larger concerns about device theft than the "average user", then plan accordingly. Find the right mix of other offered unlocks and snoop prevention mechanics as feels right to you.) > But there are important things missing. I think at this point in your post you are confusing Webauthn/FIDO keys in general and Passkeys specifically. In general, websites should absolutely allow you to register an entire keychain of public keys beyond just any single device's keys. (It's often the sign of a bad Webauthn implementation if it only allows a single key.) Passkey standards themselves are an extra couple of levels of Webauthn standards on top of that. They include things such as synchronization of keychains, including recovery keys, manufacturer attestations about keys ("this key comes from the secure hardware enclave of an iOS device"), and the use of Bluetooth LTE for local FIDO key delegations (using a QR code to kick off a handshake between your Windows PC and your Android Phone to sign something over Bluetooth LTE, and Bluetooth LTE with physical proximity only). The general goal of passkeys is to have keychains with keys from every one of your devices represented plus the ability to say that "these keys are somewhat more important" such as the keys from your personal phone as the true "master keys" of your passkey. Apple, Google, and Microsoft have all agreed to interoperate in their implementations of Passkeys. In theory, the Passkeys keychains should all eventually "merge" into a single synchronized keychain representing your entire device ecosystem, generally with your personal phone as the "lead" or "head" at the table. In practice, for now, most Passkeys operations I believe still should assume that a user has N Passkeys (and N times M keys in general). But yes, Apple is currently in the lead with Passkeys implementation (with UX in all of iOS, macOS, and Safari) and Google isn't far behind in Chrome implementation (though I hear Android is somewhat behind still) and Microsoft currently has the most "catch up" to do in terms of Passkey UX.

WorldMaker 3y ago

The PINs protect a hardware enclave full of cryptographic keys. The PIN never leaves the hardware device it was input into. (It's an equivalent to the button on a Yubikey or something of that nature and there is a reason that PINs are lumped into the same settings as biometric unlocks like Touch ID and Face ID.) It's an intelligent trade-off, of course, in threat models that involve access to the physical device for threat models that involve remote access of websites and other resources. Yes, if everything uses the same PIN on a device then that adds to the risk of someone snooping your PIN, stealing your device, and accessing many things in the process. If that is the threat model that most concerns you, then yes, this makes things worse. But PINs can't be used remotely at all and never transfer across a wire. They can't be brute forced remotely over the internet. Having someone's PIN but not the specific device that the PIN unlocks doesn't unlock anything (because you still don't have access to any of the private keys on the device without the device). Websites only know your device's public keys. If you use entirely WebAuthn, breached websites only leak public keys. If your threat model involves concerns about internet hackers or the daily breaches we see in services like haveibeenpwned, device-specific PINs are a massive improvement.

Nathanba 3y ago
Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. I think webauthn could be great for 2fa without phones. But there are important things missing. For example the google authenticator app has an established way to backup and sync now. There is no such manual backup and sync possibility for Windows Hello passkeys. It's all a bit new now. I suppose as a website owner I would have to let people register multiple passkeys and then the user only has to have one of them to successfully log in. Hm it might be okay. And of course Chrome already added sync support for their passkeys but you can't rely on everyone using Chrome.
- WorldMaker 3y ago
  > Yes I was thinking of the theft scenario, for remote usecases it is definitely safer. The thing to keep in mind is that the remote threats are bigger and more common, and the "local theft" scenarios fewer and impacting fewer people. Obviously, it is terrifying as an individual user when a device is stolen with enough PIN information. But on the other hand, you can't so easily automate stealing devices physically from people. It is much harder to steal things to anything like the same degree of mass stealing credentials in remote attacks and database breaches. For most ordinary users, they are much more at risk of remote attack or remote phishing than local theft. Device PINs are probably the right balance for the average user's threat model. (If you have larger concerns about device theft than the "average user", then plan accordingly. Find the right mix of other offered unlocks and snoop prevention mechanics as feels right to you.) > But there are important things missing. I think at this point in your post you are confusing Webauthn/FIDO keys in general and Passkeys specifically. In general, websites should absolutely allow you to register an entire keychain of public keys beyond just any single device's keys. (It's often the sign of a bad Webauthn implementation if it only allows a single key.) Passkey standards themselves are an extra couple of levels of Webauthn standards on top of that. They include things such as synchronization of keychains, including recovery keys, manufacturer attestations about keys ("this key comes from the secure hardware enclave of an iOS device"), and the use of Bluetooth LTE for local FIDO key delegations (using a QR code to kick off a handshake between your Windows PC and your Android Phone to sign something over Bluetooth LTE, and Bluetooth LTE with physical proximity only). The general goal of passkeys is to have keychains with keys from every one of your devices represented plus the ability to say that "these keys are somewhat more important" such as the keys from your personal phone as the true "master keys" of your passkey. Apple, Google, and Microsoft have all agreed to interoperate in their implementations of Passkeys. In theory, the Passkeys keychains should all eventually "merge" into a single synchronized keychain representing your entire device ecosystem, generally with your personal phone as the "lead" or "head" at the table. In practice, for now, most Passkeys operations I believe still should assume that a user has N Passkeys (and N times M keys in general). But yes, Apple is currently in the lead with Passkeys implementation (with UX in all of iOS, macOS, and Safari) and Google isn't far behind in Chrome implementation (though I hear Android is somewhat behind still) and Microsoft currently has the most "catch up" to do in terms of Passkey UX.