3 ms·

> Fortunately we don't need to wonder what to do. WebAuthN is here now and has been ready for a couple years now. i've only recently started paying attention t

by a-dub 5y ago

> Fortunately we don't need to wonder what to do. WebAuthN is here now and has been ready for a couple years now. i've only recently started paying attention to this space again, so forgive me if this is a silly question... but does the webauthn standard also include procedures for dealing with a lost, damaged or compromised authenticator device?

tehbeard 5y ago
Nope. Left as an exercise for the user and 2FA provider, and/or the service to provide an alternate recovery system.
- a-dub 5y ago
  so it's pretty much just a standard for having websites present tokens, having browsers talk to authentication devices to sign them, and then shuttling them back to the website? do the signed tokens reveal anything else about the identity of the user, or just that it's the same user that registered? can tokens that have been signed for two different websites by the same user be linked? (ie: do the public keys or signatures presented to websites a and b tell website a or b about their registration or use of the other site? does the mfa provider learn of the user's identity and registration on sites a and b?)
  - aseipp 5y ago
    In a nutshell, you've got the idea. And no: the signed tokens are for all intents and purposes random blobs (often generated literally from /dev/urandom by the server), and the browser strictly associates a WebAuthn keypair to exactly one domain, and no others. Because the browser enforces this, it means it's impossible to phish the user; even if you had the secret key for aseipp@foo.com (the music website) you stole from me, you couldn't use it for aseipp@bar.com (my bank account).
  - tehbeard 5y ago
    There is some data you can get from them (Attestation I think is what the spec calls it?) though it's just a optional request response I think, the 2fa can ignore it by itself or at users discretion? But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.
aseipp 5y ago
No, there's no standard for any of those things. "Lost" or "Damaged" devices at least are indistinguishable from the service POV: you simply cannot authenticate and need to reset your auth method. "Compromised" is a bit different; with WebAuthn you can at least attest that an authenticator device is from some known authority (e.g. this is a valid Apple device), so there's a notion of device authenticity, but this has nothing to do with whether or not the actual device is being used nefariously or with ill intention or not. Maybe you could use it as an anti-fraud signal if you do that stuff. WebAuthn in a big sense is just a browser-standardized way of a service operator storing your (abstract service users') public key, and you using the private key to sign login challenges from them, proving it is you. Every site gets a different keypair, and that's it in a nutshell. Even though this is not a password, just like any password, a lot of the mechanisms you use to recover from disaster are exactly the ones that are most vulnerable to being attacked. Any kind of flow to handle these scenarios is basically going to look a lot like how it looks now: Keep emergency recover codes that the user has to print out and use as an extreme emergency, etc. The user has an email attached and you send a magic link to that email in order to do a reset, and it will be assumed this account is secure, and if it's not, then nothing else about the reset scheme really matters. And even if mybackupemail@gmail.com is using a password, WebAuthn as a first party feature used by the service operator has a number of real concrete benefits to themselves and the user: no more credential stuffing, browser-enforced phishing immunity, and browsers make it pretty easy to use immediately with features like fingerprint readers or FaceID.
- a-dub 5y ago
  so then, as far as i can tell, the only real upgrade, in terms of real security, from the passworded web using password managers, is that under webauthn an individual password cannot be sniffed or phished since it's public key challenge->sign->response. fixing phishing is a nice big start, but i keep hearing about all these sms redirect attacks and other attacks on password reset functions. leaving that as an exercise to the reader doesn't really seem to solve the problem. (especially in events where all keys must be rotated due to lost/stolen/compromised device)
  - aseipp 5y ago
devinl 5y ago
Google's advanced security is a good example of an actual implementation of fido2 where they've had to deal with real world threats and device usage. They require multiple fido2 devices (for dealing with the lost/damaged problems). Compromise of FIDO2 devices is particularly interesting though. Specialized hardware like a yubikey rather than software based fido2 might help here, but that still leaves theft as a wide open vector. If theft is a risk for your use case, https://www.yubico.com/blog/getting-a-biometric-security-key-right/ https://www.yubico.com/blog/getting-a-biometric-security-key... could be an interesting solution or using secure hardware on your phone behind a lockscreen. Also having a password (in addition to webauthn) might be good enough for you to slow down an attacker enough for you to disable your compromised device (using another fido2 device to authenticate).

by a-dub 5y ago

tehbeard 5y ago

Nope. Left as an exercise for the user and 2FA provider, and/or the service to provide an alternate recovery system.

a-dub 5y ago
so it's pretty much just a standard for having websites present tokens, having browsers talk to authentication devices to sign them, and then shuttling them back to the website? do the signed tokens reveal anything else about the identity of the user, or just that it's the same user that registered? can tokens that have been signed for two different websites by the same user be linked? (ie: do the public keys or signatures presented to websites a and b tell website a or b about their registration or use of the other site? does the mfa provider learn of the user's identity and registration on sites a and b?)
- aseipp 5y ago
  In a nutshell, you've got the idea. And no: the signed tokens are for all intents and purposes random blobs (often generated literally from /dev/urandom by the server), and the browser strictly associates a WebAuthn keypair to exactly one domain, and no others. Because the browser enforces this, it means it's impossible to phish the user; even if you had the secret key for aseipp@foo.com (the music website) you stole from me, you couldn't use it for aseipp@bar.com (my bank account).
- tehbeard 5y ago
  There is some data you can get from them (Attestation I think is what the spec calls it?) though it's just a optional request response I think, the 2fa can ignore it by itself or at users discretion? But this data is more about the manufacturing of the 2FA device, and basically amounts to the "bin" it belongs to, like saying built in 2020, as part of batch 3. Vague enough to not really be identifiable, but useful if a flaw in a device is found in a particular model or such.

aseipp 5y ago

No, there's no standard for any of those things. "Lost" or "Damaged" devices at least are indistinguishable from the service POV: you simply cannot authenticate and need to reset your auth method. "Compromised" is a bit different; with WebAuthn you can at least attest that an authenticator device is from some known authority (e.g. this is a valid Apple device), so there's a notion of device authenticity, but this has nothing to do with whether or not the actual device is being used nefariously or with ill intention or not. Maybe you could use it as an anti-fraud signal if you do that stuff. WebAuthn in a big sense is just a browser-standardized way of a service operator storing your (abstract service users') public key, and you using the private key to sign login challenges from them, proving it is you. Every site gets a different keypair, and that's it in a nutshell. Even though this is not a password, just like any password, a lot of the mechanisms you use to recover from disaster are exactly the ones that are most vulnerable to being attacked. Any kind of flow to handle these scenarios is basically going to look a lot like how it looks now: Keep emergency recover codes that the user has to print out and use as an extreme emergency, etc. The user has an email attached and you send a magic link to that email in order to do a reset, and it will be assumed this account is secure, and if it's not, then nothing else about the reset scheme really matters. And even if mybackupemail@gmail.com is using a password, WebAuthn as a first party feature used by the service operator has a number of real concrete benefits to themselves and the user: no more credential stuffing, browser-enforced phishing immunity, and browsers make it pretty easy to use immediately with features like fingerprint readers or FaceID.

a-dub 5y ago
so then, as far as i can tell, the only real upgrade, in terms of real security, from the passworded web using password managers, is that under webauthn an individual password cannot be sniffed or phished since it's public key challenge->sign->response. fixing phishing is a nice big start, but i keep hearing about all these sms redirect attacks and other attacks on password reset functions. leaving that as an exercise to the reader doesn't really seem to solve the problem. (especially in events where all keys must be rotated due to lost/stolen/compromised device)
- aseipp 5y ago

devinl 5y ago

Google's advanced security is a good example of an actual implementation of fido2 where they've had to deal with real world threats and device usage. They require multiple fido2 devices (for dealing with the lost/damaged problems). Compromise of FIDO2 devices is particularly interesting though. Specialized hardware like a yubikey rather than software based fido2 might help here, but that still leaves theft as a wide open vector. If theft is a risk for your use case, https://www.yubico.com/blog/getting-a-biometric-security-key-right/ https://www.yubico.com/blog/getting-a-biometric-security-key... could be an interesting solution or using secure hardware on your phone behind a lockscreen. Also having a password (in addition to webauthn) might be good enough for you to slow down an attacker enough for you to disable your compromised device (using another fido2 device to authenticate).