A little red padlock? It's a start... but why not refuse to load the page if it has a form tag but no https. That's how you solve this.
Login Forms Over HTTPS, Please
111–120 of 121 posts
Re: Login Forms Over HTTPS, Please
#112Legalize insider trading; It'll fix/solve HFT;
Re: Login Forms Over HTTPS, Please
#113I love this, but would prefer they didn't re-use the "invalid certificate" icon.
As a devs, we use self signed certificates for building our products and we have trained QA to ignore the HTTPS with a slash through it as an error that is acceptable in dev.
(And ourselves for that matter)
That makes this one easy to miss.
My preference would be a browser-level warning bar to roll out over the page. Like the one used in 'this plugin is not installed'
This is a huge error and its much harder to miss that way.
Re: Login Forms Over HTTPS, Please
#114I don't know why sites don't just use HTTPS for everydamnedthing. It's 2016. SSL is not that computationally expensive and it's just easier to develop an entire site that way anyway (rather than making some pages secure and other non-secure). Just redirect everything to https and forget about it.
I agree with you, however the bureaucracy at some companies is insane.
In order for me to get a TLS certificate where I work I have to create a CSR, fill in a word document, attach those to a Jira ticket, the operations team will then hand those over to a contractor who talks to our chosen CA. Up to 10 working days(!) later I get an OV certificate back.
How I wish we were allowed to use Lets Encrypt.
Re: Login Forms Over HTTPS, Please
#115Verb in Sentence, Please.
Re: Login Forms Over HTTPS, Please
#116I'm not writing login code personally but this sounds like something fundamentally broken in the web and asking devs to fix it case by case is a complete copout. If a browser can detect this shit, why can't it fucking proxy it or do something clever to mitigate it automatically instead of putting up stupid hyroglyphs and expecting to shame developers into duplicating a bunch of work case by case and thereby probably getting it wrong in many cases? .. like.. ff detects insecure login form.. Browser DON'T FUCKING SEND CLEARTEXT PASSWORD (instead sending some encrypted bs to firefox grand central station, where it is securely forwarded through a secure backchannel? Maybe it has to talk to the isp directly who has to inject the password back into your process, and they charge u extra tax for securing your shit.. and then.. gasp.. problem solved and not every aspiring developer needs to become a cryptographer.
Passwords are stupid. The internet is broken. My Spyware infested machine and browser knows all my passwords anyway.
Note to any techies reading this.. fix this problem. Here is your killer app. Disrupt this shit.
Re: Login Forms Over HTTPS, Please
#117How about "Ads over HTTPS, please"? Can't upgrade our sites if our ad revenue drops through the floor.
I think you're the first person in this thread to explain why this problem is still allowed to exist.
Re: Login Forms Over HTTPS, Please
#118Earlier quoted context omitted.
Yes, I was about to say this - if you have a secure enough content security policy (and the browser in question supports it properly) it will be impossible for an attacker to execute their inserted Javascript (which to be able to do this anyway is also a security vulnerability). But yes, the best plan is to have HTTPS everywhere, something that looks a lot closer than it once did! Thanks NSA!
> if you have a secure enough content security policy (and the browser in question supports it properly) it will be impossible for an attacker to execute their inserted Javascript I don't follow your reasoning. Why wouldn't an MITM attacker modifying an HTTP response body to insert rogue Javascript also be able to modify the response headers to strip or alter the Content Security Policy?
Good point about MITM attacks; I assumed that we were talking about cross site scripting (XSS), but I suppose you are right.
I still am willing to bet that SSL is not impossible to MITM. Someone will manage to find a flaw in such a complex system.
Re: Login Forms Over HTTPS, Please
#119Earlier quoted context omitted.
With HTTPS, multiple different sites will have different "hashes" sent anyway, so no, it's not an improvement over just good ol' HTTPS.
Well, sure. But then you have to worry about how well the website is storing your passwords. Meh, password managers are the way to go to be honest.
Most websites with any sense dont store actual passwords, they usually store salted PBKDF hashed that are compared in constant time.
Re: Login Forms Over HTTPS, Please
#120Wow, this is still even a thing. The form, all its js assets and form api endpoint all have to be secured. And https for everything that contains code. Deploying SRI for web pages over https is also another layer of defense against js tampering. Also, sending passwords across the wire in any reversible manner is really more dangerous than is necessary. Passwords/passphrases could be salted hashed by the browser in Ja…
> Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable. This is not safe! Now an attacker just needs to intercept the hashed password and replay that, and he gets to login without knowing what the password is. Use h…
You're wrong because it's a strawman since if an attacker can intercept the hash they could as easily intercept the plaintext in your traditional server-side architecture. The attacker cannot replay a TLS unless there is a problem with it, there have been many issues in TLS stacks, but it's the most widely deployed.
Furthermore, using plaintext any further from the owner or exposed longer than is necessary is inherently less secure because your breach of https would also compromise users' passwords.