6 ms·

Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specifi

Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditional-ui/ https://developer.chrome.com/blog/webauthn-conditional-ui/ Another huge challenge is that there are so very many ways for developers to use this tech. There are a truly humbling amount of scenarios & flows one can set-up. Many of the most direct paths continue to have the user already set up an account via regular email/password, so users still end up doing the same account management anyways. I'm missing the link to the wonderful wonderful guide I spent a couple commute rides reading, but it was one of the longest most technical pieces I've read in quite a while. "Introducing the WebAuthn API" is perhaps a reasonably ok substitute. https://medium.com/webauthnworks/introduction-to-webauthn-api-5fd1fb46c285 https://medium.com/webauthnworks/introduction-to-webauthn-ap...

alsdfjkslfheu 4y ago
is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?
- rektide 4y ago
  If nothing else, it has more bits of security than a password has & so is less crackable. It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality. The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility.
  - alsdfjkslfheu 4y ago
    > Standards enable flexibility which enables possibility. what?! standards are the opposite of flexible. by definition. here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default. only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap) -- i'm blocked from adding replies, so replying here: > it does passwords not keys well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday.
    - tadfisher 4y ago
      Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.
      - crote 4y ago
        If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
        4y ago
- xoa 4y ago
  Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which is services themselves getting hacked. Password managers make it easier to change a password after a leak has happened, but moving to a proper key based infra means that leaks simply no longer matter. It doesn't matter in terms of auth if attackers get a public key. While having more hardware backing on top certainly has advantages too, it's the symmetric nature of passwords that have always made using them in a shared environment a fundamentally bad idea. Practical advantages of moving on like eliminating all the stupid legacy password policies and so on in one fell swoop are nice as well. >besides losing the option to set your own secure password that you can store offline? There is nothing inherent that would stop passkeys from being converted to base64 and printed on paper same as any key, and part of the point of them is being able to back them up all the normal ways and have them secured with a good password or other option that never leaves your own control. Which of course you can then print out.
  - ljm 4y ago
    As I recall it, this is more or less what Mozilla wanted to do with Persona back in the day. That didn’t take off, but the approach with WebAuthN is perhaps an evolution of it especially in terms of making public key crypto user-friendly. Of course, the challenge is different in a multi-device world when you want your phone, tablet and laptop to all use the same login without using a hardware key.
  - GoblinSlayer 4y ago
    If the password is properly managed, how does it matter if its hash leaks?
    - SgtBastard 4y ago
      Two major problems with holding passwords server side as hashes: 1) Every authentication attempt needs to send the password as cleartext (even if over TLS) so that the hash can be recomputed server side and compared. This gives ample opportunity for the password to be intercepted either over the wire or compromise of infrastructure server-side. Using asymmetric encryption doesn't have this vulnerabity. 2) Passwords that can be stored in the meatsack attached to the keyboard aren't as random as we'd like to think them to be, where as a secure pseudo-random function will generate keypairs with unguessable entropy. Expanding on 2) While salting and non-uniform iteration counts of hashes prevents instant compromise from rainbow tables, they only slow down adversaries generating hashes from password guesses, as the salt and iteration count will typically be leaked from the same table as the password hash. Its worth noting that while it definitely is infeasible to attempt to crack 100K+ users passwords from a password hash leak, using password spraying and especially password stuffing approaches will inevitably lead to compromise one or more accounts relatively quickly. At the other end of the spectrum, if a known high-value account can be identified, dedicating the distributed cloud resources to cracking a specific password can be a net-profitable undertaking.
- JackGreyhat 4y ago
  Your password cannot leak, because it does not exist. Passkeys can also not be phished.
  - wkat4242 4y ago
    Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes?
    - SgtBastard 4y ago
      The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance. That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself. Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.
wkat4242 4y ago
> Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. I disagree. I think it's great having it all under my own control. What's important though is to be able to add multiple keys which many sites don't offer. Having my keys under control of apple or Microsoft sounds to me like a terrible and frustratingly limited scheme. But passkeys doesn't rule out physical keys so if people want to get deeper in bed with big tech they can, while I can keep my physical keys.
Nathanba 4y ago
it still seems pretty bad ui wise, prompting me to scan a QR code on desktop: https://webauthn-conditional-ui-demo.glitch.me/create-account.html https://webauthn-conditional-ui-demo.glitch.me/create-accoun... I was ready to give up until I realized that maybe "internal sensor" means Windows Hello on my machine and yep it does. But no real user is going to click through these security sensitive popup dialogs until Windows Hello shows up as an option. My verdict is that it's still clearly only for techies. And when I cancel the dialog it prompts me to "setup my security key". Just terrible ui, nonstop popups. Edit: Firefox shows me the Windows Hello option immediately, that should be the default on desktop.
- Buttons840 4y ago
  My daughter recently had an unplanned "remote learning" day because of snow. One of my daughters assignments required her to log into an app. At school they do so by scanning a QR code they keep in the classroom. The teacher sent a picture of the QR code. I found myself in the hilariously absurd situation of needing my laptop to scan a QR code it was displaying on its own screen. I took a picture with my phone and then presented the QR back to the computer. Your comment reminded me of this.
  - francislavoie 4y ago
    I use 1Password for TOTP. It has a screenshot option to scan the QR code during setup. It's handy.
- iudqnolq 4y ago
  On Firefox on my Android phone it's phrased much better: "Use this device with screen lock". But that doesn't sound like something I'd ever want. Obviously I want to be able to log in on my computer too?
  - Nathanba 4y ago
    it seems I entirely missed the red text on Firefox that says "Your browser does not implement Conditional UI" so what Firefox did was to probably prompt for the old WebAuthn and I guess that's Windows Hello which makes a lot of sense to me. I wonder whether Firefix will also show me the QR code signin as the default on desktop once they implement it. Like you said...in my opinion this makes no sense, obviously as a desktop user using a desktop site I want to remain on my desktop hardware device. Or am I misunderstanding you and you want to log in on desktop with the same passkey that you generated on mobile? I think that is never supposed to work, it's supposed to be tied to the device.
Nathanba 4y ago
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 4y 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 4y 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.
crote 4y ago
So instead of having a physical device you own act as a second factor, you are now vendor-locked to a proprietary authentication solution for the entire login process. No thank you! The entire point of two-factor authentication is to have, well, two factors: something you know and something you have. Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untrusted code so it is likely to be compromised at some point - but at least that was somewhat excusable due to convenience making it accessible to way more people. But getting rid of the rest of the credential and solely relying on the OS is just insanity.
- mrjin 4y ago
  Not only that. It defeats the purpose of using a dedicated device.
  - rektide 4y ago
    Which the masses were never ever ever going to adopt, not in a million billion years.
- rektide 4y ago
  I didn't like how unmanageable physical devices were. If I could make a backup of those keys, I would have been happy with physical devices. But every time I make an account somewhere, I have to go add devices in triplicate? Ugh it was such an abysmal terrible experience. Physical devices are just too unreliable & too constrained as systems. Passkeys, to my knowledge, are an extension of FIDO Alliance standards. My hope is that one can bring your own provider. This would avoid the vendor lock that has you quaking.
  - danShumway 4y ago
    > My hope is that one can bring your own provider. Everyone always says this, but it's always just a hope. And given the history of the FIDO Alliance standards on backing up keys, and given the players involved, I think it's reasonable to say that people just straight-up should not use passkeys until it's not a "hope" and backup/migration actually works as part of the standard itself. Note that this doesn't mean: - Migration is allowed but not mandated. Migration must be built into the standard or else vendors will eventually introduce lock-in in the future under the guise of security. It can not be optional. - Migration is allowed through special contracts using some locked-down behind-the-scenes company-to-company transfer. I need to be able to sit down on my Linux computer with an Open Source piece of software that I compiled and I need to be able to move the keys from my iCloud account to that software. I want to assume good faith from the FIDO Alliance standards, but some of the messaging around this has been straight-up deceptive. 1Password advertised itself as solving the portability problem, but last I checked it doesn't. 1Password is device agnostic but does not allow exporting your passkey information to another account. I've run into so many scenarios where advocates straight-up misrepresent what portability means that I now give really specific tests instead, because otherwise the conversation doesn't go anywhere. I keep running into advocates that tell me "it's usable today" and in the same breath tell me "it's early days, we'll get to the portability stuff later." So the specific criteria is: if I can't compile my own software on a Linux computer and move my "keys" or whatever authentication mechanism is tied to that account into that software as a single operation without logging into and re-validating every single account individually or adding another authentication mechanism to each account, then it's not portable and I'm not using it. It needs to specifically allow for that, and there needs to be a real working Open Source project that I can run today that allows it. Otherwise, it's not actually portable today. Furthermore, if I do compile my own software and move in those keys and then I go to log into a website and a service refuses to let me log in because I've failed a hardware attestation check and I need to use an Apple device to log in -- then it's not portable. That cannot be something that the spec allows or encourages, or it's not actually portable. But (and as always, I would be thrilled to be proven wrong about this) the spec itself allows for that kind of behavior with hardware attestation with basically no downside other than a "please be a nice company and don't do this" warning, and noise from the FIDO Alliance advocates I've seen online is that they don't want to mandate a specific migration format in the spec or make migration a requirement for companies that want to advertise that they implement Passkey; they want to leave that process up to individual companies under the "hope" that those companies will do the right thing. I'm not just not adopting Passkeys, I'm actively discouraging adoption of the standard until that's fixed. I'm not signing into a locked-down ecosystem under the hope that it might become more open later in the future, maybe. There's a version of Passkeys that I would be excited about and that I would build support into my projects for, but it's not the version that exists today.
mrjin 4y ago
Wow, the main reason to use a dedicated device is to avoid someone else get access to the keys without physically accessing the device. And now the key is voluntarily surrendered.

alsdfjkslfheu 4y ago

is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?

rektide 4y ago
If nothing else, it has more bits of security than a password has & so is less crackable. It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality. The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility.
- alsdfjkslfheu 4y ago
  > Standards enable flexibility which enables possibility. what?! standards are the opposite of flexible. by definition. here's something that is better than webauthn, published and battle tested since 2018, and nobody cares: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ it have all the advantages of webauthn, plus it is truly on-device, no middle man, you can easily recover keys simply by having more than one device... no server can read or data. only silly thing is that firefox insists on shipping with the auto-fill option enabled by default. only feature missing that this thread seems to brings up is support for external usb devices (which i personally don't care for, but is probably on the roadmap) -- i'm blocked from adding replies, so replying here: > it does passwords not keys well, that is what worked on 100% the internet in 2018 (and today, ha!). But it is a data store where you have full control. ironically this is what gives true flexibility, a well designed system with fully open source implementation and apis, not spec by ad vendors as claimed before. anyway, The existing browser implementation does passwords (and bookmarks!!!) but you can extend to be a distributed yubikey if you'd like. nothing is blocking you. as I said, it is something better than a hardware store, better than a cloud broker for your identity, etc... but nobody cares. And now that FIDO has marketing from the big Advertisers everyone wants it yesterday.
  - tadfisher 4y ago
    Firefox syncs passwords, not keys. Passwords can be reused, stolen, or leaked, all of which cannot be done to WebAuthn keys.
    - crote 4y ago
      If I am not mistaken, all Passkeys implementations allow keys to be synced between multiple devices. This means it is by definition possible for them to be stolen or leaked. Webauthn keys are only secure against stealing & leaking if they are backed by a proper separate token like a Yubikey, but it seems the People That Be want us to get rid of those ASAP.
      - 4y ago
xoa 4y ago
Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which is services themselves getting hacked. Password managers make it easier to change a password after a leak has happened, but moving to a proper key based infra means that leaks simply no longer matter. It doesn't matter in terms of auth if attackers get a public key. While having more hardware backing on top certainly has advantages too, it's the symmetric nature of passwords that have always made using them in a shared environment a fundamentally bad idea. Practical advantages of moving on like eliminating all the stupid legacy password policies and so on in one fell swoop are nice as well. >besides losing the option to set your own secure password that you can store offline? There is nothing inherent that would stop passkeys from being converted to base64 and printed on paper same as any key, and part of the point of them is being able to back them up all the normal ways and have them secured with a good password or other option that never leaves your own control. Which of course you can then print out.
- ljm 4y ago
  As I recall it, this is more or less what Mozilla wanted to do with Persona back in the day. That didn’t take off, but the approach with WebAuthN is perhaps an evolution of it especially in terms of making public key crypto user-friendly. Of course, the challenge is different in a multi-device world when you want your phone, tablet and laptop to all use the same login without using a hardware key.
- GoblinSlayer 4y ago
  If the password is properly managed, how does it matter if its hash leaks?
  - SgtBastard 4y ago
    Two major problems with holding passwords server side as hashes: 1) Every authentication attempt needs to send the password as cleartext (even if over TLS) so that the hash can be recomputed server side and compared. This gives ample opportunity for the password to be intercepted either over the wire or compromise of infrastructure server-side. Using asymmetric encryption doesn't have this vulnerabity. 2) Passwords that can be stored in the meatsack attached to the keyboard aren't as random as we'd like to think them to be, where as a secure pseudo-random function will generate keypairs with unguessable entropy. Expanding on 2) While salting and non-uniform iteration counts of hashes prevents instant compromise from rainbow tables, they only slow down adversaries generating hashes from password guesses, as the salt and iteration count will typically be leaked from the same table as the password hash. Its worth noting that while it definitely is infeasible to attempt to crack 100K+ users passwords from a password hash leak, using password spraying and especially password stuffing approaches will inevitably lead to compromise one or more accounts relatively quickly. At the other end of the spectrum, if a known high-value account can be identified, dedicating the distributed cloud resources to cracking a specific password can be a net-profitable undertaking.
JackGreyhat 4y ago
Your password cannot leak, because it does not exist. Passkeys can also not be phished.
- wkat4242 4y ago
  Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes?
  - SgtBastard 4y ago
    The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance. That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself. Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.

wkat4242 4y ago

> Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. I disagree. I think it's great having it all under my own control. What's important though is to be able to add multiple keys which many sites don't offer. Having my keys under control of apple or Microsoft sounds to me like a terrible and frustratingly limited scheme. But passkeys doesn't rule out physical keys so if people want to get deeper in bed with big tech they can, while I can keep my physical keys.

Nathanba 4y ago

it still seems pretty bad ui wise, prompting me to scan a QR code on desktop: https://webauthn-conditional-ui-demo.glitch.me/create-account.html https://webauthn-conditional-ui-demo.glitch.me/create-accoun... I was ready to give up until I realized that maybe "internal sensor" means Windows Hello on my machine and yep it does. But no real user is going to click through these security sensitive popup dialogs until Windows Hello shows up as an option. My verdict is that it's still clearly only for techies. And when I cancel the dialog it prompts me to "setup my security key". Just terrible ui, nonstop popups. Edit: Firefox shows me the Windows Hello option immediately, that should be the default on desktop.

Buttons840 4y ago
My daughter recently had an unplanned "remote learning" day because of snow. One of my daughters assignments required her to log into an app. At school they do so by scanning a QR code they keep in the classroom. The teacher sent a picture of the QR code. I found myself in the hilariously absurd situation of needing my laptop to scan a QR code it was displaying on its own screen. I took a picture with my phone and then presented the QR back to the computer. Your comment reminded me of this.
- francislavoie 4y ago
  I use 1Password for TOTP. It has a screenshot option to scan the QR code during setup. It's handy.
iudqnolq 4y ago
On Firefox on my Android phone it's phrased much better: "Use this device with screen lock". But that doesn't sound like something I'd ever want. Obviously I want to be able to log in on my computer too?
- Nathanba 4y ago
  it seems I entirely missed the red text on Firefox that says "Your browser does not implement Conditional UI" so what Firefox did was to probably prompt for the old WebAuthn and I guess that's Windows Hello which makes a lot of sense to me. I wonder whether Firefix will also show me the QR code signin as the default on desktop once they implement it. Like you said...in my opinion this makes no sense, obviously as a desktop user using a desktop site I want to remain on my desktop hardware device. Or am I misunderstanding you and you want to log in on desktop with the same passkey that you generated on mobile? I think that is never supposed to work, it's supposed to be tied to the device.

Nathanba 4y ago

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 4y 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 4y 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.

crote 4y ago

So instead of having a physical device you own act as a second factor, you are now vendor-locked to a proprietary authentication solution for the entire login process. No thank you! The entire point of two-factor authentication is to have, well, two factors: something you know and something you have. Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untrusted code so it is likely to be compromised at some point - but at least that was somewhat excusable due to convenience making it accessible to way more people. But getting rid of the rest of the credential and solely relying on the OS is just insanity.

mrjin 4y ago
Not only that. It defeats the purpose of using a dedicated device.
- rektide 4y ago
  Which the masses were never ever ever going to adopt, not in a million billion years.
rektide 4y ago
I didn't like how unmanageable physical devices were. If I could make a backup of those keys, I would have been happy with physical devices. But every time I make an account somewhere, I have to go add devices in triplicate? Ugh it was such an abysmal terrible experience. Physical devices are just too unreliable & too constrained as systems. Passkeys, to my knowledge, are an extension of FIDO Alliance standards. My hope is that one can bring your own provider. This would avoid the vendor lock that has you quaking.
- danShumway 4y ago
  > My hope is that one can bring your own provider. Everyone always says this, but it's always just a hope. And given the history of the FIDO Alliance standards on backing up keys, and given the players involved, I think it's reasonable to say that people just straight-up should not use passkeys until it's not a "hope" and backup/migration actually works as part of the standard itself. Note that this doesn't mean: - Migration is allowed but not mandated. Migration must be built into the standard or else vendors will eventually introduce lock-in in the future under the guise of security. It can not be optional. - Migration is allowed through special contracts using some locked-down behind-the-scenes company-to-company transfer. I need to be able to sit down on my Linux computer with an Open Source piece of software that I compiled and I need to be able to move the keys from my iCloud account to that software. I want to assume good faith from the FIDO Alliance standards, but some of the messaging around this has been straight-up deceptive. 1Password advertised itself as solving the portability problem, but last I checked it doesn't. 1Password is device agnostic but does not allow exporting your passkey information to another account. I've run into so many scenarios where advocates straight-up misrepresent what portability means that I now give really specific tests instead, because otherwise the conversation doesn't go anywhere. I keep running into advocates that tell me "it's usable today" and in the same breath tell me "it's early days, we'll get to the portability stuff later." So the specific criteria is: if I can't compile my own software on a Linux computer and move my "keys" or whatever authentication mechanism is tied to that account into that software as a single operation without logging into and re-validating every single account individually or adding another authentication mechanism to each account, then it's not portable and I'm not using it. It needs to specifically allow for that, and there needs to be a real working Open Source project that I can run today that allows it. Otherwise, it's not actually portable today. Furthermore, if I do compile my own software and move in those keys and then I go to log into a website and a service refuses to let me log in because I've failed a hardware attestation check and I need to use an Apple device to log in -- then it's not portable. That cannot be something that the spec allows or encourages, or it's not actually portable. But (and as always, I would be thrilled to be proven wrong about this) the spec itself allows for that kind of behavior with hardware attestation with basically no downside other than a "please be a nice company and don't do this" warning, and noise from the FIDO Alliance advocates I've seen online is that they don't want to mandate a specific migration format in the spec or make migration a requirement for companies that want to advertise that they implement Passkey; they want to leave that process up to individual companies under the "hope" that those companies will do the right thing. I'm not just not adopting Passkeys, I'm actively discouraging adoption of the standard until that's fixed. I'm not signing into a locked-down ecosystem under the hope that it might become more open later in the future, maybe. There's a version of Passkeys that I would be excited about and that I would build support into my projects for, but it's not the version that exists today.

mrjin 4y ago

Wow, the main reason to use a dedicated device is to avoid someone else get access to the keys without physically accessing the device. And now the key is voluntarily surrendered.