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.

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)

Well to a first approximation I would say phishing is about 1000x more widespread and dangerous to the average user than SMS-based attacks, so the impact is pretty immediate and significantly larger. I haven't seen any indication of SMS-based attacks (which often require compromises of cell providers or inside jobs, and are often targeted rather than being en masse activities) being in the same league, or even the same sport, as daily phishing attacks. But then again I'm wrong often.

You'll almost certainly never get rid of a long tail of compromises in this area, and some tricky parts will be left up to the service provider to get right (there's nothing stopping someone from bungling the password reset feature, for instance.) But at the end of it all, WebAuthn is here today, it axes multiple major vulnerability classes that are used to compromise accounts globally every day, and any future improvements are going to start from that point.

To be honest, at this point the only people I see hanging onto passwords in 2021 desperately are nothing but computer people like us who have been doing it this way for 20+ years and don't want to change out of stubbornness rather than any kind of actual analysis (this exact dynamic explains a lot of things, actually.) Most normal people already use e.g. federated login mechanisms like FB Login or password managers and don't care if the underlying auth mechanism changes this way.

> But at the end of it all, WebAuthn is here today, it axes multiple major vulnerability classes that are used to compromise accounts globally every day, and any future improvements are going to start from that point.

and to be honest, i'm glad to see it! it's huge!

i just push back because history tells us that leaving something that big as an exercise to the reader means that it will be gotten wrong and, well, i'm not sure if you really get too many shots at getting the whole web to upgrade authentication methods.

there's been some interesting articles in vice magazine recently where they talk about the expense of mitm'ing someone's text messages only costing about $5. i'm sure as soon as phishing goes away, as a result of something like this, all the fraud will shift to the next easiest weakness, which seems like it would be underspecified standards for resetting one's public keys/credentials/etc.

> 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 worst problem: these recovery codes are not protected from government seizure or theft. A password? I can keep that in my head and, sans government-planted keyloggers or tactical use of a wrench (https://xkcd.com/538/), the government or thief doesn't stand a chance.

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... 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).

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

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?)

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).

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.