Hacker News Reader

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

View on HN

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

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.

Exactly! What is the purpose of being "logged in" if when you then go to browse the rest of the site you are no longer actually "logged in" (because the secure HTTPS cookie isn't being sent on those insecure http: pages).

Reply on news.ycombinator.com