HTTPS Does NOT Make Passwords Secure

Does Not Address Server Security

[IanM]

Quote from the OP at: https://www.webmasterworld.com/webmaster/4830145.htm [webmasterworld.com]

Nonsecure Collection of Passwords will trigger warnings in Chrome 56 for www.example.com

Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as “Not Secure” unless the pages are served over HTTPS.

The following URLs include input fields for passwords or credit card details that will trigger the new Chrome warning. Review these examples to see where these warnings will appear, and so you can take action to help protect users’ data. The list is not exhaustive.
....

The new warning is the first stage of a long-term plan to mark all pages served over the non-encrypted HTTP protocol as “Not Secure”.

On the OP's topic, I had a lengthy discussion on this with Mozilla devs. The point I make is that HTTPS does NOT make passwords secure anyway. The vast majority of password thefts occur on the webserver or SQL server of the host, and HTTPS only protects data in transit, not once it arrives at the host.

Sending and storing passwords in plaintext is the issue which ought to be focused on. It has been at the root of almost all of the major security breaches. Forcing the use of HTTPS does absolutely nothing to fix this. In fact, by acting as a 'snake oil solution' for the real problem, it may prevent a proper fix being implemented.

[edited by: not2easy at 4:15 pm (utc) on Dec 29, 2016]
[edit reason] See Sticky/TOS [/edit]

[csdude55]

Amen, brother! Back when I did web design for clients, I can't tell you how many times I had to give that same sermon... which usually resulted in the client just finding someone to do what they wanted and not give them a hard time.

Seriously... I can't tell you how many e-commerce sites wanted credit cards emailed to them in plain text!

[toidi]

encryption is not the correct way to protect passwords

but it is good for PR as it makes it look like they are doing something about the problem

[robzilla]

What's your point, though? Nobody's saying HTTPS ensures proper storage of passwords; a web browser has no control over that. Would you say that transferring passwords over HTTPS rather than unencrypted HTTP is not a welcome security improvement?

[encyclo]

Sounds like a straw man argument to me. Using HTTPS protects the transmission of the password, no-one is claiming that it protects the data on the server. From the OP:

Sending and storing passwords in plaintext is the issue which ought to be focused on.

That's two issues, not one, and you are deliberately conflating them to try to make your point. HTTPS helps with the sending but not the storing.

[IanM]

The point is that giving irrelevant or incorrect advice is never a good idea.

The warning is triggered on the presence of a password field. All the treatises on password handling that I've ever read, say that encryption is not the correct way to process passwords.

The practical consideration is that the inexperienced webmaster might otherwise note that numerous websites are being hacked and passwords stolen, and decide to find out how to protect passwords properly. Thus, he might avoid that happening to his site.

But, he's been told that implementing HTTPS has made his passwords safe. So, he doesn't.

[keyplyr]

The point is that giving irrelevant or incorrect advice is never a good idea... he's been told that implementing HTTPS has made his passwords safe

IMO this is only your assumption. I see no evidence anyone is being told that.

[IanM]

Password field present, warning shown. No password field.. no warning shown. Seems like that's telling me there is a password problem.. which will be fixed by HTTPS. Evidence enough to me.

Since we mention evidence though, show me the evidence that MITM attacks are a high priority security risk.

If the real-world evidence of such attacks is so scant (and it is, they barely feature at all in security stats) then why is the whole IT world dedicating a gazillion man-hours of time to protecting against them, even on sites which contain no sensitive information, beyond perhaps a throwaway forum password?

That is not a sensible deployment of personnel, when there are far more serious security issues which urgently need addressing. It's almost like this is being used as an excuse to avoid devoting time or money to the real issues.

[keyplyr]

Password field present, warning shown. No password field.. no warning shown

Yes, at first. Then later (to be determined) the warnings will display on all sites not secure.

Also, and this should be of interest to all webmasters, the upcoming HTTP/2 protocol with significant speed increases, is only supported on sites with HTTPS.

[robzilla]

Since we mention evidence though, show me the evidence that MITM attacks are a high priority security risk.

The priority is irrelevant, unencrypted HTTP traffic remains a security risk. Are you suggesting otherwise?

From a web browser's perspective, unencrypted HTTP is a high priority issue, relative to all other issues it has control over. Secure storage of passwords is a non-issue, because what do you suggest a web browser should do about that?

They're different issues and you're conflating them.

[IanM]

You evidently haven't read my writeup on the subject. Browsers should provide hashing.

Unencrypted HTTP a high priority issue? Why? Since MITM is the one and only risk mitigated by HTTPS, at the risk of repeating myself, please justify this assertion with documented evidence of MITM incidents which led to bulk theft of passwords. -Or for that matter, which led to any nontrivial security breach.

From some fairly extensive searching of vulnerability listings I could find only two documented MITM incidents. Neither involved bulk theft of passwords. If you can provide substantially more evidence than that of the danger posed by MITM, then I will accept that you have a point. I'm talking about actual, verifiable evidence though, not theorizing.

If you read the IT press at all, I am sure you will be aware of the massive scale of some of the website data thefts which have occurred in 2016. Many of these involved multiple millions of stolen passwords. Most of these involved attacks on Web or database servers. A few, attacks on client computers or insecure admin-level accounts. None, to my knowledge, involved MITM.

The case for having browsers hash passwords automatically is, I think, overwhelmingly greater than the case for imposing HTTPS on sites which carry no sensitive data.

[robzilla]

I've read your Mozilla posts. Your ideas don't seem to be gaining much traction.

Man-in-the-middle attacks are an issue with unencrypted traffic, but so is eavesdropping. You "read the IT press," so I'm sure you've heard of Prism. How's that for scale?

[IanM]

I fail to see how Prism is related to this. If a judge orders that data be handed over, then it has to be handed over. If it has been encrypted then it must be decrypted. It is about as far removed from man-in-the-middle as it gets.

I've asked on a number of IT forums for evidence of MITM attacks which led to theft of passwords. So far, the response has been zero. Add this to the paucity of such reports on IT security investigation sites, and you have to admit, it's a strange situation.

The fact that the proponents are not prepared to listen to counterarguments, only makes for stronger evidence that they know it is pointless from a security perspective, but have undisclosed reasons to pursue it.

[robzilla]

The NSA, like agencies in other countries, taps into internet communications, and any traffic over HTTP, as well as POP3, FTP and other unencrypted protocols, flows openly and can be read by anyone with access. On a smaller scale, this applies to public/shared wifi networks as well. Rest assured passwords and other sensitive data have been intercepted this way, or the data used as a link in a chain to gain access to other systems. It's a security and privacy problem that needs to be fixed, and that's why HTTPS is being pushed aggressively.

I don't see why you need to downplay one security enhancement to promote another, especially when the latter depends so much on the former: client-side hashing is pointless without HTTPS.