9 ms·
Which would capture passwords in plaintext sent from the user side, no?
by Zee2 8y ago
Which would capture passwords in plaintext sent from the user side, no?
- Pxtl 8y agoYes, but browsers give huge warnings about password fields on non-SSL sites. Password in the clear won't happen with any major website.
- osrec 8y agoDo they? I don't think so... Try http://login.ebiquity.com http://login.ebiquity.com Do you see any warnings in your browser? I see no warnings in Chrome.
- earenndil 8y agoThis is shown in firefox: https://files.catbox.moe/srdxhe.png https://files.catbox.moe/srdxhe.png
- kalleboo 8y agoSafari shows a red "Website not secure" in the address bar like this https://i.imgur.com/6DXzZ8G.png https://i.imgur.com/6DXzZ8G.png
- ThePadawan 8y agoChrome changes the "Not secure" in the address bar from grey to red (and displays a red explamation mark symbol there) when data is entered into the form.
- SamBam 8y agoWhich version/OS? I have the latest Chrome (69.0.3497.100) on macOS 10.13.3, and I see no red exclamation mark. Nothing changes or warns me at all when I start entering data in the fields. https://imgur.com/a/Q0rZWOS https://imgur.com/a/Q0rZWOS Maybe you have a browser extension, or setting turned on that I'm missing?
- _fzslm 8y agoIt's not enabled by default on the latest Chrome, at least for macOS (10.14). You can enable it using the #enable-mark-http-as flag, after which HTTP pages with password fields will look like this: https://i.imgur.com/8kKWPjr.png https://i.imgur.com/8kKWPjr.png
- ThePadawan 8y agoThis is in Version 69.0.3497.100 (Official Build) (64-bit), Windows 10. This happens regardless of extension (i.e. in an incognito window).
- confounded 8y agoThe box controls the DNS; majorwebsite.com points to any sever the attacker likes. The only defense is HSTS/certificate-pinning, for sites previously visited with that browser & device (it’s a TOFU security model). HN has HSTS, but not Reddit, or my credit union, or my local pizza place, or Kaiser Permanente, etc. etc. etc. EDIT: I believe e.g. Chrome and Firefox bake in some major certificates, which would also likely flag MITM attacks, for those sites. EDIT II: Someone responded below (since deleted) that you’d also need that cert to be signed by a CA your browser trusts, which is true. My explanation is faulty/poor. Better informed discussion of attacks further down the thread!
- deleted 8y ago[deleted]
- kupiakos 8y agoThat's assuming the box can generate certificates trusted by the target machines - there's a reason the CN field exists.
- ardy42 8y ago> That's assuming the box can generate certificates trusted by the target machines - there's a reason the CN field exists. If you're dumb enough to install one of these boxes on your network, you might also be dumb enough to install an attacker-provided root certificate on your PC.
- VMG 8y agoBut if you ask your user to install a CA, why not simply ask him to install malware? Is it to circumvent antivirus?
- tialaramex 8y agoThe X.500 series Common Name is a weird thing to fixate on here. It's an arbitrary free text "name". The only reason it's even sometimes useful in the modern era is that the CAB BRs say it has to match one of the SANs so it will probably be a DNS name. But even there good luck, it took until 2016 or so to get the last stragglers to obey that rule properly without "misunderstanding" it and unlike SANs it isn't defined to be DNS A-labels so it may have arbitrary Unicode text. Most browsers stopped even looking at CN or only do so for people's crappy home grown private CAs Anyway, what makes certs trustworthy isn't the CN, it's a chain of two or more digital signatures leading to a trusted root. And the CN in that root, while it had to be truthful when written, may be twenty years old, so it's nonsense now.
- stef25 8y agoThere's a little "not secure" at the top in Chrome, something most users will simply ignore.
- skrebbel 8y agoNot so little when the user is also typing into a password field
- wild_preference 8y agoI can imagine an HN commenter scrutinizing things when encountering that warning, but it's not very actionable for anyone else. "Ah, okay, it's not so secure, whatever that means... but I still want to login and do what I set out to do."
- mike-cardwell 8y agoIf the site is non-SSL, then there's nothing stopping somebody in control of the network from replacing all "password" fields with plain "text" fields, and then applying a custom font to them so every character entered is displayed as a "•"
- rjmunro 8y agoThat's basically what a password field already is. That would make no difference to anything - the password would be sent over the network in exactly the same way either way.
- michaelt 8y agoRight, but some browsers display a small warning message when you select a password field on a non-https page [1] If instead of a password field it's a text field with a custom font, no such warning will be presented. [1] https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/ https://blog.mozilla.org/security/2017/01/20/communicating-t... http://http-password.badssl.com/ http://http-password.badssl.com/
- mike-cardwell 8y agoNo. The point of switching out a password field for a text field is to prevent the browser from warning about the existence of a password field on a non-HTTPs secured page. This is a well known, and old trick.
- achairapart 8y ago> so this was a linked comment from a thread 3 years ago.... While major websites already were on SSL, a lot of websites didn't and there were no browser warnings yet.