I'm not sure why the admins of nanog's site should
particularly care about appeasing the js tinfoil hat
set. i mean, computers computing! who will stop this
madness!
Unless your $DAYJOB consists solely of not using browsers whatsoever, you cannot function without javascript.
Ironically it seems that the way to disable javascript is to install a browser extension. which is both javascript and outside the browser sandbox. *those* i fear.
Mike
Can't it be both?
Mobile code (javascript) has a long a storied history of security
disaster. So yes, I surf with javascript disabled and when I run in to
a web site that I can't use without it about 75% of the time I back up
to the search engine and pick a different web site because I don't
want to let my computer run the horrid crapware the site author thinks
I should allow him to run.
Does controlling what I allow my computer to run make me a member of
the tinfoil hat set? Watching folks around me use their equipment,
it's apparent that it does. Is it good security hygiene? Why yes, it's
that too.
Regards,
Bill Herrin
Billions of people and by far the vast majority of users on the planet use js enabled sites. Would that it were that it was even in the top 1% of security problems we face.
The fact is, nobody in devland cares whatsoever about this non-issue. that the nanog site ran without the need of js is more of an accident of history more likely than not: if it ain't broke don't fix it.
If you want an actual verifiable current day problem which is a clear and present danger, you should be running as fast as you can to retrofit every piece of web technology with webauthn to get rid of over the wire passwords. that is infinitely more serious than some age-old js breaches. and it is especially critical for the equipment that nanog members run every day to configure, monitor, and manage. Ironically, it requires... javascript browser-side.
I think I posted about this before and got a collective ho-hum.
Mike
Nope. chrome://settings/content/javascript for Chromium, about:config ->
javascript.enabled in Firefox.
- Matt
If you want an actual verifiable current day problem which is a clear
and present danger, you should be running as fast as you can to retrofit
every piece of web technology with webauthn to get rid of over the wire
passwords.I think I posted about this before and got a collective ho-hum.
Yeah, it came up last week on an ARIN group and I called it "flavor of
the month." It does some interesting things on a strictly technical
level but it's a solution in search of a problem. You're not at
significant risk that your password will be captured from inside an
encrypted channel and that's all webauthn adds to other widely
deployed technologies that also haven't caught on.
that is infinitely more serious than some age-old js
breaches. and it is especially critical for the equipment that nanog
members run every day to configure, monitor, and manage. Ironically, it
requires... javascript browser-side.
You think sending encrypted passwords over the wire is more of a
problem than intentionally allowing untrusted code to run on the same
machine that contains personally sensitive information? Really? Do you
understand that when malicious code gains a sufficient foothold on
your computer, webauthn protects exactly squat?
Regards,
Bill Herrin
If you want an actual verifiable current day problem which is a clear
and present danger, you should be running as fast as you can to retrofit
every piece of web technology with webauthn to get rid of over the wire
passwords.I think I posted about this before and got a collective ho-hum.
Yeah, it came up last week on an ARIN group and I called it "flavor of
the month." It does some interesting things on a strictly technical
level but it's a solution in search of a problem. You're not at
significant risk that your password will be captured from inside an
encrypted channel and that's all webauthn adds to other widely
deployed technologies that also haven't caught on.
Passwords over the wire are the *key* problem of computer security. Nothing else even comes close. One only needs to look at the LinkedIn salting problem to know how trivial it is to exploit password reuse. They are a big company and they still absolutely failed. There are a trillion smaller sites who are just as vulnerable, and all it takes is one.
that is infinitely more serious than some age-old js
breaches. and it is especially critical for the equipment that nanog
members run every day to configure, monitor, and manage. Ironically, it
requires... javascript browser-side.You think sending encrypted passwords over the wire is more of a
problem than intentionally allowing untrusted code to run on the same
machine that contains personally sensitive information? Really? Do you
understand that when malicious code gains a sufficient foothold on
your computer, webauthn protects exactly squat?
Um, they are not encrypted. The are plain text after TLS unencrypts them. That is their Achilles Heal.
Yes, that is way more of a problem than code running in a sandbox. The one -- mischief. The other -- buh-bye retirement savings.
Please, get a clue.
Mike
Passwords over the wire are the *key* problem of computer security. Nothing
else even comes close.
Hmm, a bold claim, but I'm confident the author will have strong support for
their position.
One only needs to look at the LinkedIn salting problem
That was a stored password problem, not a passwords-over-the-wire problem,
but OK. I'm sure we'll be back on track shortly.
to know how trivial it is to exploit password reuse.
Not sure how exploiting password reuse causes problems with passwords over
the wire. Halfway through the paragraph now, still haven't seen anything
talking about passwords over the wire. No doubt the next sentence will
address the claim in detail, though.
They are a big company and they still absolutely failed.
Starting to think that maybe there isn't going to be the solid justification
for the topic sentence that I'd originally assumed.
There are a trillion smaller sites who are just as vulnerable, and all it
takes is one.
A trillion smaller sites that are just as vulnerable... to passwords over the
wire?
Wait, this is the end of the paragraph. How odd, not a single statement in
support of the assertion. Perhaps it's not, in fact, true, then, that
passwords over the wire are the *key* problem of computer security.
While I do think webauthn is a neat idea, and solves at least one very real
problem (credential theft via phishing), you do an absolutely terrible job
of making that case.
- Matt
Passwords over the wire are the *key* problem of computer security. Nothing
else even comes close.Hmm, a bold claim, but I'm confident the author will have strong support for
their position.One only needs to look at the LinkedIn salting problem
That was a stored password problem, not a passwords-over-the-wire problem,
but OK. I'm sure we'll be back on track shortly.
You can't have a stored password problem if you never see them.
While I do think webauthn is a neat idea, and solves at least one very real
problem (credential theft via phishing), you do an absolutely terrible job
of making that case.
see RFC 4876, it is not about phishing. not even a little bit. Never has been. Please get a clue.
Mike
PS: you clearly lack imagination. password reuse is the default. $SHINYNEWSITE has only to entice you to enter your reused password which comes out in the clear on the other side of that TLS connection. basically password phishing. you can whine all you like about how stupid they are, but you know what... that is what they average person does. that is reality. js exploits do not hold a candle to that problem.
Mike
The ironic catch 22 is that libsodium.js runs in the browser to encrypt the passwords before being sent over the wire. But happens to be javascript.
Whilst I do *absolutely* agree with you that "A Configuration Profile Schema
for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not about
phishing, not even a little bit", I'm not entirely sure how it advances your
argument.
- Matt
sorry, 7486.
Mike
The point is that shared passwords over the net have nothing to do with phishing per se, and everything to do with if I get one of your passwords, i get them all. phishing is one way to do that. but there are plenty of other ways too. gross incompetence as was the case of LinkedIn was my impetus hacking up a pre-webauthn which Steven and Paul happened to see which caused us to write our experimental RFC. We weren't think about phishing at all, or at least I wasn't.
Here's what i wrote about it in 2012.
https://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html
Mike
Two equally large problems -- neither of which have anything to do with
encryption in transport -- are backend security and password strength.
In the former case, we've seen an ongoing parade of security breaches
and subsequent dataloss incidents. That parade is still going on.
In the latter case, despite years of screaming from the rooftops, despite
myriad enforcement attempts in code, despite another parade of incidents,
despite everything, we still have people using "password" as a password.
As a side note, I've found it nearly impossible to get users to
understand that there is a qualitative and quantitative difference
between "password used for brokerage account" and "password used for
little league baseball mailing list".
The minor problem of passwords-over-the-wire pales into insignificance
compared to these (and others -- but that's a long list).
---rsk
Um, those are exactly the consequences of passwords over the wire. If you didn't send "password" over the wire, nobody could guess that's your password on your banking site. "password" to unlock your local credential store of private keys is far less serious because they have to have access to the device that hosts those credentials. "password" to your bank, on the other hand, is just a https away.
the other thing this allows is people to have a single extremely good password that doesn't change to protect the local credential store, and also protects you from the idiotic corpro security theater which requires passwords to be changed so often that you have to write them down. on my own local machine, i get to dictate the policy not some corpro security thespian.
I guess that's why best practices for authentication encourage the adoption
of HTTP Digest authentication. No password over the wire == no problems!
- Matt
Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong?
Mike
But you said that *passwords on the wire* were the biggest problem. Digest
auth solves that. Also, you don't have to store the plain-text password.
- Matt