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?

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 [email protected] 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.

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)

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.

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.

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.

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

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

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.

Generally speaking, you are "sharing" your password with an entity that you wish to share or at least access other resources too. There has to be a degree of trust relationship of some sort, regardless of what scheme you choose for authentication.

Getting the relationship right is the really complicated, or at least, the most important part of the equation, the rest is tiddlywinks! There is no point getting all steamed up over one authentication scheme or another unless the whole transaction is considered end to end.

Passwords can work and work well, in certain circumstances, as do all the other authentication methods. They all have success and failure modes of one sort or another.

"The realm of free software is home to surveillance by the network" - what does that actually mean?

Easy! Let's look at the words one by one:

* "The network", implied being the only one relevant to the reader, must therefore be The Internet

* "surveillance" means "observation", "looking at things", in the most general sense. How can The Internet look at things? The computers don't have agency; so we must revise "The Internet" to mean the people on the internet. Which is, for all intents and purposes, everyone.

* "Realm" means kingdom. In common usage, "Realm of..." means "everything relating to/comprising/surrounding ...". So "realm of free software" is just, well, free software and how it's used.

* Being "home to" something means that something is always there when we talk about concepts that lack agency, like the ability of people to look at things. "A is home to B" means that B is inherently a part of A.

So, putting it all together, we have:

>People knowing exactly what you make and how it's used is a part of making and using free software.

Or, to say it less clumsily:

>When you make free software, everyone can see how they're made and used

Simplifying further to:

>Anyone can see how free software is made and used

...which is, of course, the entire point. Duh.

Anyone; there you go, you're welcome!

PS: speech like that is exactly what Orwell wrote against back in the day[1]. You will enjoy reading it.

[1]https://www.orwellfoundation.com/the-orwell-foundation/orwel...

Free software being out in the open makes analyzing it to find zero days easier, but also can be analyzed as a group. some companies, Google being a very notable case, are quite public about their efforts to evaluate and improve free software. So no, your distilled point is not the one I was trying to make.

There's one notable exception to that: the root of your trust (a device you decrypt) needs to be something you know, rather than something you have like a token. You can have private keys on that encrypted device, and you can have physical tokens as a second factor, but unless your root of trust is something in your head it can be taken from you.

Password managers already fixed this. Your password is unique per website so it doesn't matter if the service knows it since they could already login as you anyway.

An attacker may have breached the service and exfiltrate passwords. The service may have a config error and log plain-text passwords to an unsecured elasticsearch instance. The service provider may have bad security practices and store the password in plain text or using an insecure hashing scheme.

All of these problems go away if you use some sort of asymmetric authentication since the public part is by definition public.

Well, if you use corporate device, you implicitly trust them, don't you? Some even sign put signature on a paper agreeing what the corporate body can do to you. Perhaps MITM your encrypted traffic with corporate installed root cert or whatever.

Otherwise if you use your own device, in the age of encrypted HTTP and other stuff - No, an adversary or corporate firewall cannot simply read your password.

Well, if you use microsoft, you implicitly trust them, don't you

Well, if you use <insert ISP>, you implicitly trust them, don't you

Well, if you use the internet, you implicitly trust them, don't you

I may have to submit to the inspection of traffic whether I trust them or not and even if I trust them to have the best intentions, things go wrong and firewalls get hacked - and all of a sudden that nice capability is in the hands of an attacker. So even if I do trust them, I prefer mechanisms that work asymmetric.

A disk encryption password doesn't need to be shared with anyone for it to work?

> WebAuthN is here now and has been ready for a couple years now.

At last, I can give my users all the inconvenience of 2FA, but without a second factor.

That's not entirely true, as demonstrated by constructions like PAKE. It is a shame, though, that the adoption is almost nonexistent.

An English captain ran a private experiment in 1601 to see what happened when sailors were fed lemon juice. The group receiving lemon juice had zero cases of scurvy. The group not receiving lemon juice experienced 40% mortality from scurvy.

(Imagine running an experiment today with 40% mortality in the control group!)

The results were reported, but nothing was done with them. The navy had to rediscover the same fact a few hundred years later.

But there was nothing wrong with the model.

https://www.bbc.co.uk/news/uk-england-37320399 - this is a BBC article about James Lind, who did an experiment in 1747. Not too sure about four ships in 1601 - there are no sources in the link above. Also, he was a Scot, not English. He was of course a Brit too (1707-)

The results probably were reported but they were probably not distributed effectively. Nowadays we have the internet to vilify entire populations, within seconds. Back then, you had to get a pamphlet printed that a few 100 people would read.

"Sailors who ate the ship's rats were inadvertently protecting themselves - as the animal synthesizes its own vitamin C."

So there you go. If you run out of shipmates and lemons: eat the rats!

The navy is not a decentralized organization. Distribution of the results is not a concern.

Unintentionally ...

This is in 1747: https://www.bbc.co.uk/news/uk-england-37320399

The fact that the British navy still had no institutional knowledge of scurvy hundreds of years later is the point I'm making. They didn't know how to deal with it despite the fact that a cure had been known for several thousand years, and the navy itself had received James Lancaster's report over a hundred years prior. The navy's behavior reflects nothing other than a very severe failure that would have been trivial to fix at any time.

The adoption barriers that caused the navy to kill thousands upon thousands of its own men over a period of centuries did not reflect any difficulty in preventing scurvy. It was always easy. They reflected the fact that adoption barriers are very large no matter what the context is, and absolutely overwhelming evidence, such as a 100% reduction in the incidence of a disease that ordinarily kills 40% of your manpower, is not enough to bypass them.

The adoption of a practice is at most tenuously related to the effectiveness of a practice. That is not how people adjust their behavior.

What point are you making?