Live data from Hacker News

Login Forms Over HTTPS, Please

hacks.mozilla.org

41–50 of 121 posts

Re: Login Forms Over HTTPS, Please

#41
Prominent? A crossed over lock icon in the address bar? Try again.

A prominent warning would be something ridiculous, like a full page cover saying "THIS PLACE IS NOT SECURE – HERE BE DRAGONS!" or something. Browser vendors should do more of this for egregious errors on the publisher's side. Unless users complain loudly that stuff is uncomfortable and broken and scary and what not, you can write articles like this every day of the week and publishers still won't do anything about it, and the only users to care will be the geeks who understand what the damn icon means in the first place.

Re: Login Forms Over HTTPS, Please

#43

I 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.

[deleted]

Re: Login Forms Over HTTPS, Please

#44

The most secure approach is to serve everything over HTTPS AND redirect HTTP to HTTPS WITH "Strict-Transport-Security" header [1]. Even this is not perfect, but it's the best approach available AFAIK. 1. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

You can also submit your site for inclusion on the HSTS preload lists:

https://hstspreload.appspot.com/

This fixes the remaining hole of the first visit.

However, one warning, if you like privacy, you should turn off HSTS or clear it on browser close at least. It's effectively a giant supercookie and it provides little security benefit over checking URLs for SSL yourself.

Re: Login Forms Over HTTPS, Please

#45

I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…

> If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. If the cookie is set through HTTPS, the browser won't send it when loading HTTP resources. So the cookie won't be exposed that way. We should still be using HTTPS for all traffic in 2016.

If a website only uses HTTPS for login, then it has to set a cookie for HTTP as well, otherwise how will the user navigate the site after login? From top of my head, you can implement this by associating the randomly generated session ID that you assign to all visitors, with the login ID.

Regardless, what jordanlev said still applies. The session can be hijacked.

Re: Login Forms Over HTTPS, Please

#46

I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…

> If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. If the cookie is set through HTTPS, the browser won't send it when loading HTTP resources. So the cookie won't be exposed that way. We should still be using HTTPS for all traffic in 2016.

> If the cookie is set through HTTPS, the browser won't send it when loading HTTP resources.

If the cookie is set through HTTPS and does not have the Secure flag set, the browser will happily send it along when loading HTTP resources.

Re: Login Forms Over HTTPS, Please

#47

I have recently deployed Content Security Policy (CSP) on a website. When I first looked at violation reports, my jaw dropped. The amount of malware (rouge extensions, toolbars, viruses, ...) that is blocked is staggering. If you really want to help your (clueless) users, never ever serve a login, registration or credit card form without CSP. It really helps - at least until the malware catches on (I already see "Kas…

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!

Re: Login Forms Over HTTPS, Please

#48
post #2

> If you’re submitting your login form over HTTPS, that’s good, but it’s not enough. You have to deliver* the form over HTTPS too.* I'm glad they mentioned it. Too many people think their sites are secure if logged in sessions use https and everything else is http. Their example is that an attacker could insert JavaScript to steal the password, however they could just as well change the form target from https to http…

So how do you avoid this?

Re: Login Forms Over HTTPS, Please

#49

I have recently deployed Content Security Policy (CSP) on a website. When I first looked at violation reports, my jaw dropped. The amount of malware (rouge extensions, toolbars, viruses, ...) that is blocked is staggering. If you really want to help your (clueless) users, never ever serve a login, registration or credit card form without CSP. It really helps - at least until the malware catches on (I already see "Kas…

Is there a pre-built tool to capture and manage CSP violation reports? I believe its mainly just a POST request with some JSON right?

Re: Login Forms Over HTTPS, Please

#50

I 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.

Also, SNI is available since IE 7, so the times where you need an extra IPv4 address for every SSL domain are almost over.

(Or, are there any websites still trying to support IE 6 or 5.5, apart from large online shops?)

Post reply on HN