4 ms·

We all know this is mostly meaningless. The real 'feature' of webAuth is 3rd party attestation. Your bank and soon every other service will see how 'cheap' it

We all know this is mostly meaningless. The real 'feature' of webAuth is 3rd party attestation. Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one. When you talk about webAuthn that is what you are talking about in the end. 3rd party attestation. Which in the end will be the end all "privacy respecting" (/s) advertisement profiling tech in the years to come.

prhrb 4y ago
Can someone explain more?
- thealchemistdev 4y ago
  [flagged]
  - lima 4y ago
    Beautiful example of the limits of AI - it simply reiterates the comment in a seemingly informative way, but it doesn't actually understand it, so it really just states the same thing but more verbosely. Knowing nothing about Passkeys, it's also subtly wrong. What exactly is your point?
    - misnome 4y ago
      Not just verbosely, but with the implied contempt!
    - namaria 4y ago
      It's a bit anticlimactic how the hype is just dying down and everyone involved is just pretending they weren't just weeks ago crying wolf about the whole thing. Still I feel vindicated in my early assessment that it was mostly just empty hype about some chatbot.
    - deleted 4y ago
      [deleted]
  - antiloper 4y ago
    What value does this comment add?
- Scion9066 4y ago
  Basically, for hardware backed devices like phones and physical security keys, there's an attestation certificate that is shared by all devices of that model. This can allow a site that wants higher security for some reason to require this kind of proof that the key is protected from copying in hardware (eg bound to a specific device and can't be stolen via malware, theoretically) due to it being a model known to be secure. I'm not aware of specific sites requiring this though. It is recommended that sites don't require it: "It is important to be aware that requiring attestation is an invasive policy, especially when used to restrict users' choice of authenticator. For some applications this is necessary; for most it is not. [...] When in doubt, err towards being more permissive, because using a passkey is more secure than not using a passkey. [...] we recommend that you do not require a trusted attestation unless you have specific reason to do so." https://developers.yubico.com/Passkeys/Passkey_relying_party_implementation_guidance/Attestation/ https://developers.yubico.com/Passkeys/Passkey_relying_party... More info: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
  - vlovich123 4y ago
    That seems like truly terrible advice. The only example given: > It may still be useful to request and store attestation information for future reference - for example, to warn users if security issues are discovered in their authenticators - but we recommend that you do not require a trusted attestation unless you have specific reason to do so. If that’s the only application, that communication should happen through alternate channels like your browser/OS vendor itself. Having random websites be responsible for communicating whether a given attestation may indicate compromise is less than helpful and the probability of that actually happening correctly is about 0. Oh and given all the breaches, if there is a compromise, the attacker now has a helpful list of customers using compromised authenticators. One application seems to be to use this to try to replace captcha but I wonder what kind of impact that will have on 3p authenticators. Without extra details, it may be right to be concerned this is a massive landgrab as to how people access online services.
ale42 4y ago
This doesn't need to happen. Having such a function in KeePassXC is important so that there's a sufficient user base not attested by big groups.
- alex7734 4y ago
  KeePass's userbase is negligible, banking apps didn't care about those that use rooted phones and won't care about KeePass users. My guess is that the big groups will lobby for this to be turned into a checkbox in some "best practices" list that auditors will enforce into the usual suspects in the name of "safety and security": banks, shopping sites, government sites, etc.
  - flangola7 4y ago
    What do rooted phones have to do with anything? I use my credit union's app on my rooted, no google play services phone frequently.
    - unaindz 4y ago
      A lot of bank apps refuse to work if they detect your device as rooted/failing safetynet. My bank used to do it but they either stopped caring or more probably magisk now handles it so the apps can't tell.
pabs3 4y ago
I hear that the big tech vendors (Apple at least) aren't going to do attestable keys.
- ksjadfhiskwfh 4y ago
  What do you mean? Apple already offer it. They are still to officially publish a spec, but already published rate limits for 3rd party apps attested requests on the official docs and since 2021 people are documenting how they are updating their IDs on AAGUID fields on already available attested requests.
  - ivlad 4y ago
    It’s about attested keys, not attested apps. Apple does not attest their software-backed FIDO keys (they call them passkeys).
  - gdubchcb 4y ago
    this is wrong. you're confusing with app attestation. the other reply to this comment is also wrong. passkey lack the attestation content because the spec doesn't provide for the case being discussed on another thread... cloud backed up keys. attestation field, per current spec, must attest the 3rd party own the key and it only lives in a single placed (original intent was harware on client validated by vendor keys there)... now obviously we know apple google backup your keys on their cloud, so they cannot attest anything per current spec. don't takes that as a instance on privacy. they are rushing changes to the spec. as soon as they can attest keys that are shared with their clouds they will do.
lima 4y ago
> Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one. If that's what they want, they can have it today via OAuth/OIDC (and many sites do just that). It's not a panacea - Google & Co catch some spam accounts but not all of them and not always before the damage is already done. Passkeys/WebAuthn improve the situation by giving site operators more choices.
- gdubchcb 4y ago
  not even close the same thing. oauth/oidc gives too much signal to the identity providers. it's a 1990s solution at the time advertisers were writing the specs alone. and the implementation required oath-nascar-sponsorship pattern to have dozen of providers. no bank would accept that. webauth is a spec of this time, were it's still owned by advendors, but with a couple device vendors now for a semblance of balance. and it also solve the implementation issue of having to show too many logos on the login page. so, no, it wasn't possible before webauth. webauth solves the oauth issues for 3rd party attestation with a semblance of anonymity (which is meaningless if both party exchange data on back channels)
znpy 4y ago
Isn’t this similar to the trust issues for the x509 CA model? Basically you’re implicitly trusting that no other CA among those trusted by common browsers will emit a certificate for your domain. While this isn’t really nice for website certificates, and while there are some safeguards (although the strong ones got deprecated, like http key pinning) … once you go down to the granularity of a single user… not sure how that pans out.
- Scion9066 4y ago
  Attestation is more like: The passkey is from this model of security key/phone. That can then be used to have a list of allowed devices if you really need hardware backed security for example (eg you provide all your users in your org with specific security keys and don't want them registering anything else). It's not recommended to use the attestation part unless you really need it though as it restricts user choice.
endgame 4y ago
After the success of EME, why would anyone expect any different?

prhrb 4y ago

Can someone explain more?

thealchemistdev 4y ago
[flagged]
- lima 4y ago
  Beautiful example of the limits of AI - it simply reiterates the comment in a seemingly informative way, but it doesn't actually understand it, so it really just states the same thing but more verbosely. Knowing nothing about Passkeys, it's also subtly wrong. What exactly is your point?
  - misnome 4y ago
    Not just verbosely, but with the implied contempt!
  - namaria 4y ago
    It's a bit anticlimactic how the hype is just dying down and everyone involved is just pretending they weren't just weeks ago crying wolf about the whole thing. Still I feel vindicated in my early assessment that it was mostly just empty hype about some chatbot.
  - deleted 4y ago
    [deleted]
- antiloper 4y ago
  What value does this comment add?
Scion9066 4y ago
Basically, for hardware backed devices like phones and physical security keys, there's an attestation certificate that is shared by all devices of that model. This can allow a site that wants higher security for some reason to require this kind of proof that the key is protected from copying in hardware (eg bound to a specific device and can't be stolen via malware, theoretically) due to it being a model known to be secure. I'm not aware of specific sites requiring this though. It is recommended that sites don't require it: "It is important to be aware that requiring attestation is an invasive policy, especially when used to restrict users' choice of authenticator. For some applications this is necessary; for most it is not. [...] When in doubt, err towards being more permissive, because using a passkey is more secure than not using a passkey. [...] we recommend that you do not require a trusted attestation unless you have specific reason to do so." https://developers.yubico.com/Passkeys/Passkey_relying_party_implementation_guidance/Attestation/ https://developers.yubico.com/Passkeys/Passkey_relying_party... More info: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
- vlovich123 4y ago
  That seems like truly terrible advice. The only example given: > It may still be useful to request and store attestation information for future reference - for example, to warn users if security issues are discovered in their authenticators - but we recommend that you do not require a trusted attestation unless you have specific reason to do so. If that’s the only application, that communication should happen through alternate channels like your browser/OS vendor itself. Having random websites be responsible for communicating whether a given attestation may indicate compromise is less than helpful and the probability of that actually happening correctly is about 0. Oh and given all the breaches, if there is a compromise, the attacker now has a helpful list of customers using compromised authenticators. One application seems to be to use this to try to replace captcha but I wonder what kind of impact that will have on 3p authenticators. Without extra details, it may be right to be concerned this is a massive landgrab as to how people access online services.

ale42 4y ago

This doesn't need to happen. Having such a function in KeePassXC is important so that there's a sufficient user base not attested by big groups.

alex7734 4y ago
KeePass's userbase is negligible, banking apps didn't care about those that use rooted phones and won't care about KeePass users. My guess is that the big groups will lobby for this to be turned into a checkbox in some "best practices" list that auditors will enforce into the usual suspects in the name of "safety and security": banks, shopping sites, government sites, etc.
- flangola7 4y ago
  What do rooted phones have to do with anything? I use my credit union's app on my rooted, no google play services phone frequently.
  - unaindz 4y ago
    A lot of bank apps refuse to work if they detect your device as rooted/failing safetynet. My bank used to do it but they either stopped caring or more probably magisk now handles it so the apps can't tell.

pabs3 4y ago

I hear that the big tech vendors (Apple at least) aren't going to do attestable keys.

ksjadfhiskwfh 4y ago
What do you mean? Apple already offer it. They are still to officially publish a spec, but already published rate limits for 3rd party apps attested requests on the official docs and since 2021 people are documenting how they are updating their IDs on AAGUID fields on already available attested requests.
- ivlad 4y ago
  It’s about attested keys, not attested apps. Apple does not attest their software-backed FIDO keys (they call them passkeys).
- gdubchcb 4y ago
  this is wrong. you're confusing with app attestation. the other reply to this comment is also wrong. passkey lack the attestation content because the spec doesn't provide for the case being discussed on another thread... cloud backed up keys. attestation field, per current spec, must attest the 3rd party own the key and it only lives in a single placed (original intent was harware on client validated by vendor keys there)... now obviously we know apple google backup your keys on their cloud, so they cannot attest anything per current spec. don't takes that as a instance on privacy. they are rushing changes to the spec. as soon as they can attest keys that are shared with their clouds they will do.

lima 4y ago

> Your bank and soon every other service will see how 'cheap' it is to fight spam and abuse simply by restricting accounts attested by [apple,google,microsoft] and nobody else, specially 'None' like this one. If that's what they want, they can have it today via OAuth/OIDC (and many sites do just that). It's not a panacea - Google & Co catch some spam accounts but not all of them and not always before the damage is already done. Passkeys/WebAuthn improve the situation by giving site operators more choices.

gdubchcb 4y ago
not even close the same thing. oauth/oidc gives too much signal to the identity providers. it's a 1990s solution at the time advertisers were writing the specs alone. and the implementation required oath-nascar-sponsorship pattern to have dozen of providers. no bank would accept that. webauth is a spec of this time, were it's still owned by advendors, but with a couple device vendors now for a semblance of balance. and it also solve the implementation issue of having to show too many logos on the login page. so, no, it wasn't possible before webauth. webauth solves the oauth issues for 3rd party attestation with a semblance of anonymity (which is meaningless if both party exchange data on back channels)

znpy 4y ago

Isn’t this similar to the trust issues for the x509 CA model? Basically you’re implicitly trusting that no other CA among those trusted by common browsers will emit a certificate for your domain. While this isn’t really nice for website certificates, and while there are some safeguards (although the strong ones got deprecated, like http key pinning) … once you go down to the granularity of a single user… not sure how that pans out.

Scion9066 4y ago
Attestation is more like: The passkey is from this model of security key/phone. That can then be used to have a list of allowed devices if you really need hardware backed security for example (eg you provide all your users in your org with specific security keys and don't want them registering anything else). It's not recommended to use the attestation part unless you really need it though as it restricts user choice.

endgame 4y ago

After the success of EME, why would anyone expect any different?