Hacker News Reader

Comment by bdamm | Hacker News Reader

The author's conclusions are naive on a couple of fronts:

o Passwords ARE fundamentally broken and they do not put you in control. Passwords must be shared to work, therefore they can never truly be secret. Only a private/public key pair can even hope to authenticate an entity.

o Surveillance is present in all neighborhoods. The realm of free software is home to surveillance by the network, and attacks on the software ranging from distribution to zero days to common misconfigurations.

To top it off, the author perpetuates an anti-pattern, which is to place faith in the idea of password policies at all. NIST has recognized the pointlessness of password policies and now simply recommend that passwords are compared against databases of known passwords.

Fortunately we don't need to wonder what to do. WebAuthN is here now and has been ready for a couple years now.

View on HN

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

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.

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

"Passwords must be shared to work"

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?

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

Nope. I was making my point using a reflection of the language in the original blog post, where the author was talking about the free software "home" being free of surveillance. This was apparently different from the "home" of Apple and Facebook etc, where the user is buying into surveillance. My point is that it isn't, there are still vectors into installations made of free software.

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.

> o Passwords ARE fundamentally broken and they do not put you in control. Passwords must be shared to work, therefore they can never truly be secret.

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.

>Passwords must be shared to work, therefore they can never truly be secret.

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 adversary with network access (looking at you, corporate firewalls) can read your password as well, not only your computer and the service. If the site uses a CDN, then it's likely that the endpoint for the TLS connection is the edge node, not the service itself and that the connection is re-encrypted from the node to the service (or even on an unencrypted connection from there on).

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.

> An adversary with network access (looking at you, corporate firewalls)

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 corporate device, you implicitly trust them, don't you

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

Yes. If you don't trust microsoft and you use windows, than it doesn't matter what authentication system you use. If you used rsa keys for auth then you would still have a problem because microsoft could steal those keys.

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

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.

> Passwords must be shared to work, therefore they can never truly be secret.

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.

> Passwords must be shared to work, therefore they can never truly be secret.

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

That's probably an interesting lesson in its own right: PAKE originated in the early 90s and if it's still facing adoption barriers that suggests that the model is fundamentally untenable.

Not really. Compare https://www.johndcook.com/blog/2008/03/25/innovation-ii/

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.

Deploying the scientific method to decide something looks quite obvious to us in these days of Bill Gate's efforts to inject minute sensors into us all under the guise of vaccination or something 8)

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!

https://en.wikipedia.org/wiki/James_Lancaster#Scurvy

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

"In 1601 Captain Admiral James Lancaster unintentionally performed an experimental study of lemon juice as a preventive for scurvy."

Unintentionally ...

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

The unintentional part was that he had an experimental group and a control group. The experiment itself was not unintentional; he was already aware that the lemon juice should prevent scurvy. That's why the one ship of four that got the lemon juice was the ship he was on.

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?

we've also had kerberos since the 80s, passwords are never shared it's all digests

And how do you protect your secret keys, if passwords are fundamentally broken?

SQRL seems like a good option that incorporates public/private keys as an alternative to passwords

Reply on news.ycombinator.com