4 ms·
We could warn "this is the same as site X which is HTTP". If it's a throw away, that is fine. If it's not, that might matter.
by derrida 13y ago
We could warn "this is the same as site X which is HTTP". If it's a throw away, that is fine. If it's not, that might matter.
- IgorPartola 13y agoWhen you enter your password into an input on a page served over HTTP, it is already game over.
- derrida 13y agoNot if you use a throwaway, crappy password, that you do not care gets compromised.
- ajanuary 13y agoYour proposal, as it stands, doesn't warn the user until /after/ they've typed a non-throwaway password into a site served over http. You'd need to warn them before they even start typing a password in on an http page.
- mistercow 13y agoIdeally yes, but almost no sites send passwords as they are typed. The only likely situation where that would be a problem is if the site itself is compromised, in which case nothing can save you.
- nitrogen 13y agoNot just a site compromise; a path compromise (malicious exit node, shady ISP, or fake WiFi access point) can inject Javascript in an unencrypted page. CA-signed SSL with cert pinning prevents MITM injection.
- cbr 13y agoYou could do that. As you type into any <input type="password"> the browser would buffer the text and not send it through to the DOM immediately. When you hit enter, leave the field, submit the form, etc then it'd get sent through to the DOM where it'd be available to (potentially malicious) javascript. While the password is in the buffer the browser could check for "non-throwaway password + http" and block it if need be. This does require the browser to know which passwords are which, though, at which point it might as well be entering them for you (and only being willing to do that over https).
- rmc 13y agoWhat percentage of internet users do you think know what "HTTP" means?