5 ms·

In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to m

In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to migrate your passkeys between providers is a great step forward, I'm glad this is being implemented. Lots of complaints about passkeys and "big tech paternalism" in the comments here, and frankly I don't think ya'll deal with the middle of the bell curve user base that much. I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support. State of the art in industry is basically trying to understand every action that is happening on a device (via mobile phone network providers, location, their actions across multiple other sites, etc. etc. through vendors providing this type of intelligence... by vacuuming up all your data) to understand if fraud is happening by seeing if you can even trust the device that is getting the SMS. Every time we make a step forward in privacy, this gets harder and harder (fingerprinting devices is basically pointless now, so how do I tell if this should be a trusted device or not) so there is a driving force against improving user privacy coming from these vendors. Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support. Would I like passkeys to be more like ssh keys? um, maybe but I don't care about it one bit in practice. I use passkeys for everything I can and I've never once seen friction. The average user does not want to deal with backing up their passkeys or even thinking about them, heck most of them don't. If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.

ndriscoll 2y ago
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices. People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.
- Groxx 2y ago
  Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea. High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.
- MarkMarine 2y ago
  You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation. There are businesses and their employees trying to influence passkeys to push more towards their business models, because this does shut down a whole avenue of fraud and associated fraud fighting tools that are no longer needed, so there is a boatload of money out there trying to make passkeys worse. Comment on the spec and make your voice heard please.
- lxgr 2y ago
  Where are you still seeing attestation? Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties. Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.
  - ndriscoll 2y ago
    That's good to hear. I don't see passkeys anywhere right now because browsers don't have software implementations and my computer isn't capable of a hardware one, which incidentally is part of why I'm not a fan of forcing it on people.
    - lxgr 2y ago
      Bitwarden has a software implementation that’s been working well for me at least in Firefox. I believe it should work in Chrome as well.
deleted 2y ago
[deleted]
crote 2y ago
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec Rip out resident keys altogether. They aren't needed. You can get 99.9% of the benefits of Passkeys by using non-resident keys - literally the only drawback is that you'd need to enter a username. Resident keys essentially kill physical tokens. Without resident keys a $10 token can support thousands of websites. With resident keys? A couple dozen, if you're lucky.
- the_svd_doctor 2y ago
  > Resident keys essentially kill physical tokens. Can you elaborate? I'm curious. Is there a storage problem?
  - vaylian 2y ago
    Yes, exactly. Resident keys take up storage space. This article that was updated 5 months ago says that the most recent yubikey can support up to 100 discoverable credentials: https://support.yubico.com/hc/en-us/articles/360013790319-How-many-accounts-can-I-register-my-YubiKey-with https://support.yubico.com/hc/en-us/articles/360013790319-Ho... That might sound like a lot, but given that we want to achieve a migration to passwordless across the internet, you will quickly run out of storage space if every shop on the internet wants a dedicated keypair on your device. Non-resident keys are so much better, because you won't need to worry about this limitation.
- MarkMarine 2y ago
  Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.
  - vaylian 2y ago
    I understand your enthusiasm for passkeys and I think there are real benefits, especially for non-technical users. But likewise, there is also enthusiasm for the objectively more secure hardware tokens. Residential keys are a problem for hardware tokens. So yes, we are living in different worlds. But what we all want is to migrate to more secure authentication methods. And pushing non-residential keys to the wayside just for the convenience of not needing to remember user names feels like a bad trade-off.
lxgr 2y ago
> I use passkeys for everything I can and I've never once seen friction. That’s great for you, but they don’t currently work like that for anyone - using anything other than Chrome or Safari (many sites perform broken user agent based support detection) - using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why) - not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least) Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user). > If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments. I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.
- acdha 2y ago
  The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.
- MarkMarine 2y ago
  There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people. You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point. So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see. >Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs. >using iOS and Android without a 3rd party password manager Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept) I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer. Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed

ndriscoll 2y ago

> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices. People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.

Groxx 2y ago
Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea. High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.
MarkMarine 2y ago
You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation. There are businesses and their employees trying to influence passkeys to push more towards their business models, because this does shut down a whole avenue of fraud and associated fraud fighting tools that are no longer needed, so there is a boatload of money out there trying to make passkeys worse. Comment on the spec and make your voice heard please.
lxgr 2y ago
Where are you still seeing attestation? Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties. Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.
- ndriscoll 2y ago
  That's good to hear. I don't see passkeys anywhere right now because browsers don't have software implementations and my computer isn't capable of a hardware one, which incidentally is part of why I'm not a fan of forcing it on people.
  - lxgr 2y ago
    Bitwarden has a software implementation that’s been working well for me at least in Firefox. I believe it should work in Chrome as well.

deleted 2y ago

[deleted]

crote 2y ago

> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec Rip out resident keys altogether. They aren't needed. You can get 99.9% of the benefits of Passkeys by using non-resident keys - literally the only drawback is that you'd need to enter a username. Resident keys essentially kill physical tokens. Without resident keys a $10 token can support thousands of websites. With resident keys? A couple dozen, if you're lucky.

the_svd_doctor 2y ago
> Resident keys essentially kill physical tokens. Can you elaborate? I'm curious. Is there a storage problem?
- vaylian 2y ago
  Yes, exactly. Resident keys take up storage space. This article that was updated 5 months ago says that the most recent yubikey can support up to 100 discoverable credentials: https://support.yubico.com/hc/en-us/articles/360013790319-How-many-accounts-can-I-register-my-YubiKey-with https://support.yubico.com/hc/en-us/articles/360013790319-Ho... That might sound like a lot, but given that we want to achieve a migration to passwordless across the internet, you will quickly run out of storage space if every shop on the internet wants a dedicated keypair on your device. Non-resident keys are so much better, because you won't need to worry about this limitation.
MarkMarine 2y ago
Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.
- vaylian 2y ago
  I understand your enthusiasm for passkeys and I think there are real benefits, especially for non-technical users. But likewise, there is also enthusiasm for the objectively more secure hardware tokens. Residential keys are a problem for hardware tokens. So yes, we are living in different worlds. But what we all want is to migrate to more secure authentication methods. And pushing non-residential keys to the wayside just for the convenience of not needing to remember user names feels like a bad trade-off.

lxgr 2y ago

> I use passkeys for everything I can and I've never once seen friction. That’s great for you, but they don’t currently work like that for anyone - using anything other than Chrome or Safari (many sites perform broken user agent based support detection) - using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why) - not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least) Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user). > If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments. I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.

acdha 2y ago
The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.
MarkMarine 2y ago
There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people. You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point. So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see. >Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs. >using iOS and Android without a 3rd party password manager Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept) I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer. Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed