--- mike@mtcc.com wrote: From: Michael Thomas <mike@mtcc.com> 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! --------------------------------------------- Not the tin foil hat crowd, security. Computers be computing with or without security. Many turn off JS. Especially in this crowd. The only time I wanted to use the site anyway was to find a thread as I can't seem to find them well in search engines. For example, what was the thread about SOHO firewalls and pfsense not too long ago? I can't remember what everyone was saying about a pfsense replacement as pfsense is no longer what it was. I am having to greenfield my home network and want to find a nerdable "dual WAN' firewall. That's off topic, though, as it's just a home network question. scott
On 4/23/20 4:13 PM, Scott Weeks wrote:
--- mike@mtcc.com wrote: From: Michael Thomas <mike@mtcc.com>
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! ---------------------------------------------
Not the tin foil hat crowd, security. Computers be computing with or without security. Many turn off JS. Especially in this crowd. The only time I wanted to use the site anyway was to find a thread as I can't seem to find them well in search engines. For example, what was the thread about SOHO firewalls and pfsense not too long ago? I can't remember what everyone was saying about a pfsense replacement as pfsense is no longer what it was. I am having to greenfield my home network and want to find a nerdable "dual WAN' firewall. That's off topic, though, as it's just a home network question.
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
On Thu, Apr 23, 2020 at 04:30:28PM -0700, Michael Thomas wrote:
Ironically it seems that the way to disable javascript is to install a browser extension.
Nope. chrome://settings/content/javascript for Chromium, about:config -> javascript.enabled in Firefox. - Matt
On Thu, Apr 23, 2020 at 4:13 PM Scott Weeks <surfer@mauigateway.com> wrote:
--- mike@mtcc.com wrote:
I'm not sure why the admins of nanog's site should particularly care about appeasing the js tinfoil hat set.
Not the tin foil hat crowd, security.
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On 4/23/20 4:40 PM, William Herrin wrote:
On Thu, Apr 23, 2020 at 4:13 PM Scott Weeks <surfer@mauigateway.com> wrote:
--- mike@mtcc.com wrote:
I'm not sure why the admins of nanog's site should particularly care about appeasing the js tinfoil hat set. Not the tin foil hat crowd, security. 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.
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
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas <mike@mtcc.com> wrote:
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On 4/23/20 6:20 PM, William Herrin wrote:
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
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas <mike@mtcc.com> wrote: 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
On Thu, Apr 23, 2020 at 06:31:04PM -0700, Michael Thomas wrote:
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
On 4/23/20 7:35 PM, Matt Palmer wrote:
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
On Thu, Apr 23, 2020 at 06:31:04PM -0700, Michael Thomas wrote: 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
On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote:
On 4/23/20 7:35 PM, Matt Palmer wrote:
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.
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
On 4/23/20 8:48 PM, Matt Palmer wrote:
On 4/23/20 7:35 PM, Matt Palmer wrote:
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. Whilst I do *absolutely* agree with you that "A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not about
On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote: phishing, not even a little bit", I'm not entirely sure how it advances your argument.
sorry, 7486. Mike
On 4/24/20 4:58 PM, Michael Thomas wrote:
On 4/23/20 8:48 PM, Matt Palmer wrote:
On 4/23/20 7:35 PM, Matt Palmer wrote:
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. Whilst I do *absolutely* agree with you that "A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not about
On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote: phishing, not even a little bit", I'm not entirely sure how it advances your argument.
sorry, 7486.
Mike
Shall we play a game? https://en.wikipedia.org/wiki/Mastermind_(board_game)
On 4/24/20 5:01 PM, Bryan Holloway wrote:
On 4/24/20 4:58 PM, Michael Thomas wrote:
On 4/23/20 8:48 PM, Matt Palmer wrote:
On 4/23/20 7:35 PM, Matt Palmer wrote:
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. Whilst I do *absolutely* agree with you that "A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not about
On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote: phishing, not even a little bit", I'm not entirely sure how it advances your argument.
sorry, 7486.
Mike
Shall we play a game?
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-jo... Mike
On 2020-04-23 7:31 p.m., Michael Thomas wrote:
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas <mike@mtcc.com> wrote: 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
On 4/23/20 6:20 PM, William Herrin wrote: trillion smaller sites who are just as vulnerable, and all it takes is one.
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.
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.
On 4/23/20 6:20 PM, William Herrin wrote:
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
On Thu, Apr 23, 2020 at 4:57 PM Michael Thomas <mike@mtcc.com> wrote: 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.
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
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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.
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
On 4/26/20 7:32 AM, Rich Kulawiec wrote:
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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. 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).
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.
On Sun, Apr 26, 2020 at 07:59:24AM -0700, Michael Thomas wrote:
On 4/26/20 7:32 AM, Rich Kulawiec wrote:
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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. 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).
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.
I guess that's why best practices for authentication encourage the adoption of HTTP Digest authentication. No password over the wire == no problems! - Matt
On 4/26/20 5:07 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 07:59:24AM -0700, Michael Thomas wrote:
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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. 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). 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
On 4/26/20 7:32 AM, Rich Kulawiec wrote: password on your banking site. I guess that's why best practices for authentication encourage the adoption of HTTP Digest authentication. No password over the wire == no problems!
Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong? Mike
On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
On 4/26/20 5:07 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 07:59:24AM -0700, Michael Thomas wrote:
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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. 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). 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
On 4/26/20 7:32 AM, Rich Kulawiec wrote: password on your banking site. I guess that's why best practices for authentication encourage the adoption of HTTP Digest authentication. No password over the wire == no problems!
Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong?
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
On 4/26/20 8:39 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
On 4/26/20 5:07 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 07:59:24AM -0700, Michael Thomas wrote:
On Thu, Apr 23, 2020 at 07:56:30PM -0700, Michael Thomas wrote:
$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. 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). 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
On 4/26/20 7:32 AM, Rich Kulawiec wrote: password on your banking site. I guess that's why best practices for authentication encourage the adoption of HTTP Digest authentication. No password over the wire == no problems! Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong? 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.
You clearly know everything, while Steven, Paul, myself and the collective wisdom of w3c know nothing, so I'm out. Mike
On Mon, Apr 27, 2020 at 7:14 AM Michael Thomas <mike@mtcc.com> wrote:
On 4/26/20 8:39 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong? 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.
Correct. You need only store the realm/user/password digest. The chief problem with digest authentication is that the web site has no control over the UI. Among the many issues, this makes it tricky to reliably capture a digest in the first place without the server at least briefly knowing the password. I don't know if webauthn corrects this or makes similar blunders.
You clearly know everything, while Steven, Paul, myself and the collective wisdom of w3c know nothing, so I'm out.
Respectfully, if you didn't know that http digest authentication doesn't require server-side password storage, and more importantly don't simply admit it now that you've been informed, how trustworthy can your understanding of web authentication be? I can't speak to Steven, Paul, the w3c or any other non-posters to this thread that you wish to employ in an appeal to authority fallacy but with due respect, I think you hold a myopic view of network security. For better or worse, security is a zero-sum game. The budget stays proportional to the value of the asset being protected. When you spend it on low-impact improvements you don't have it for the many improvements with a higher impact than whether a web site knows the password you chose for that web site. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 4/27/20 8:35 AM, William Herrin wrote:
On 4/26/20 8:39 PM, Matt Palmer wrote:
On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
Which exactly zero deployment. And you need to store the plain-text password on the server side. What could possibly go wrong? 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. Correct. You need only store the realm/user/password digest. The chief
On Mon, Apr 27, 2020 at 7:14 AM Michael Thomas <mike@mtcc.com> wrote: problem with digest authentication is that the web site has no control over the UI. Among the many issues, this makes it tricky to reliably capture a digest in the first place without the server at least briefly knowing the password. I don't know if webauthn corrects this or makes similar blunders.
Webauthn corrects this by not using passwords at all. It uses public key crypto which has the nice property that the thing that the server remembers is, um, public. A compromise of public keys -- unlike unsalted password hashes in the LinkedIn case -- does no harm. That was the insight that Paul, Steven and I had with RFC 7486 back in 2012, as we mashed together two different ways going about that in our experimental rfc. I'll stand by my initial stance: passwords over the wire remain the largest security hole on the net because their reuse means you only have to target the weakest sites to harvest them. Worse, you can create an active attack to get people to just give you their passwords by setting up some interesting site that requires an account whose actual purpose is to harvest passwords. Digest does exactly nothing to deal with that problem. Also, says wikipedia about digest: Disadvantages[edit <https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&action=edit§ion=5>] There are several drawbacks with digest access authentication: * The website has no control over the user interface presented to the end user. * Many of the security options inRFC 2617 <https://tools.ietf.org/html/rfc2617>are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacyRFC 2069 <https://tools.ietf.org/html/rfc2069>mode * Digest access authentication is vulnerable to aman-in-the-middle (MITM) attack <https://en.wikipedia.org/wiki/Man-in-the-middle_attack>. For example, a MITM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity * Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password^[5] <https://en.wikipedia.org/wiki/Digest_access_authentication#cite_note-5> * It prevents the use of a strong password hash (such asbcrypt <https://en.wikipedia.org/wiki/Bcrypt>) when storing passwords (since either the password, or the digested username, realm and password must be recoverable) So my memory doesn't seem to be completely wrong here. It's been ages since I've thought about digest.
I can't speak to Steven, Paul, the w3c or any other non-posters to this thread that you wish to employ in an appeal to authority fallacy but with due respect, I think you hold a myopic view of network security. For better or worse, security is a zero-sum game. The budget stays proportional to the value of the asset being protected. When you spend it on low-impact improvements you don't have it for the many improvements with a higher impact than whether a web site knows the password you chose for that web site.
With webcrypto, you can do whatever you want these days, and use whatever UI you want. Webauthn is primarily about replacing user-facing passwords from what I can tell, but it seems like it was completely informed by crypto dongles and the business of selling them. While that might be fine for high value network equipment, etc, it adds a huge amount of complexity in what otherwise is a pretty straightforward use of public key cryptography: user enrolls their public key into the server auth backend (bound to some identity), you log in by the server sending you a nonce, etc which the browser signs with the corresponding public key which the server verifies. Done. Maybe I should do this again now that webcrypto is here instead of my janky javascript implementation. Trying to get webauthn to work with just local credentials was like pulling teeth and frighteningly complex for something that should be pretty straightforward. It would extremely disheartening if the best was the enemy of the good. Mike
participants (7)
-
Bryan Holloway -
Matt Palmer -
Michael Thomas -
Raymond Burkholder -
Rich Kulawiec -
Scott Weeks -
William Herrin