I see a lot of websites (including Stackoverflow) using this authentication mechanism:

  1. Client authenticates under HTTPS and gets back a session id.
  2. Client drops back to HTTP and accesses secure pages using HTTP, passing the session id to prove that authentication took place.

What's the point of using HTTPS to protect authentication if the man-in-the-middle can simply steal the resulting session id and act as the authenticated client? I understand that session will eventually expire but that still gives the attacker a pretty long window of opportunity to mount an attack.

2 Answers 2


Because the session-id is transfered on an unsecure HTTP connection, an attacker will be able to impersonate the user. What he doesn't know is the users password, the login is done with HTTPS.

User passwords should be protected even better than the access to a site, because often users reuse their passwords on different sites. With such a password, other (more important) sites are compromised as well.

In other words, with switching between HTTP and HTTPS you endanger only your own site, with sending passwords over HTTP you endanger other sites as well. In case of StackOverflow you would endanger all sites connected with the users OpenId account.


it simply can avoid leaking username/password. in your scenario MITM can avoid security. in other word fooling users.

however there may be some mitigation, such as session id is per IP/Country. so if someone from another ip(probably someone who MITMed the id) request page, session expire.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .