2 ms·
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
by 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 agoso 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 agoWell 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.
- a-dub 5y ago> 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.
- mschuster91 5y ago> 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/ https://xkcd.com/538/), the government or thief doesn't stand a chance.