2

On some websites, the login page (where you enter your login details) is served by a regular HTTP connection with no encryption. However, once I login, the page immediately switches to a secure HTTPS connection when displaying my account details, etc. It seems that using SSL after the password is entered is pointless, as an attacker can already intercept the connection and get the login details. Is securing the data after the login is entered have any security benefit whatsoever, or is it just a false sense of security?

An example of this is the Corsair Force website.

schroeder
  • 125,553
  • 55
  • 289
  • 326

3 Answers3

6

Especially on a login page the entire page should be https. Making, of all pages, the login page http and putting the https under a button is bad practice in my book.

This makes it a lot easier to perform MiTM/SSL strip attacks by replacing the https action under the button with a simple http link and no one can tell unless they inspect the source (as buttons don't show the link they are referring to as opposed to regular links in the content). And even when inspecting the source, as some browsers reload the page when showing source, there is no certainty.

Happy to hear reasons that contradict this, but I don't see why a login page should EVER be http on purpose when the rest of the site is https other than insecure development of the site.

user3244085
  • 1,173
  • 6
  • 13
2

It seems that using SSL after the password is entered is pointless, as an attacker can already intercept the connection and get the login details.

No, the credentials itself would usually be transferred securely. Before your browser sends anything out a SSL/TLS connection is established, which is then used for the actual application data. Note however, that this is only true in case there is no active man in the middle manipulating the site or login form.

Nevertheless, I don't think that there are any compelling reasons in this day and age not to encrypt everything. This has a couple of advantages over any sort of mixed approach.

First of all it is much harder to mess things up. There have been enough examples in the past, where the login itself was secured, but the session cookie for intance, was not. Firesheep was famously exploiting this to hijack sessions and a lot of big players were vulnerable to this type of attack.

Another common attack are stripping attacks. You may very well serve all of your links via a secure connection, but a man in the middle can basically try to replace every occurrence of https with http. sslstrip is tool doing this automatically on-the-fly and its up to your server configuration to block these requests.

Additionally, you can make use of HTTP Strict Transport Security when serving your content via SSL/TLS only. This makes absolutely sure that browsers won't even bother trying to connect to your service without establishing a secure connection in the first place.

Another important thing to note is that you can't be certain the site hasn't been tampered with by an active man in the middle. Obviously enough such an entity could manipulate the form itself in a way that your browser would indeed send out your credentials unencrypted or to somewhere completely different, rendering your whole authentication scheme useless.

However, there is another point, which at least in my view is the most important one. By exclusively offering your service via SSL/TLS you are effectively securing the privacy of your users to a certain degree. This is something Edward Snowden has mentioned just recently in his TED talk. He gave the example that you can't buy a book from Amazon without the government knowing about it, because Amazon is serving most of their sites via simple HTTP and only uses HTTPS for the checkout itself. This is true for most sites, and it is a shame, because it basically means that the governments of this world always know what you are up to.

Back in the day it was argued that performance is an issue, which was the most prevailing argument against using SSL exclusively. I don't think this is true anymore. These days it is relatively cheap to get extra performance and SSL/TLS are both optimized in a way so that previously negotiated connections can easily be reused.

Karol Babioch
  • 1,247
  • 8
  • 10
  • 2
    This answer highlights the exactly incorrect thinking about SSL that leads to many attacks. The only way that you can know the form action is the real one instead of a man in the middle attack, is to be certain that it was delivered by the host that you trust with an SSL certificate. Transport security is only one very small piece of the SSL puzzle. Authentication of the remote host is much more valuable. – trognanders Mar 20 '14 at 23:45
  • Well, ok, if you assume an active man in the middle you are right, but I think the question was more about whether or not the credentials would be transferred in the clear. But your point adds even more weight to my argument to **always** use SSL/TLS, which is why I added another paragraph describing the issue. – Karol Babioch Mar 20 '14 at 23:48
  • Well, to be in the position where plaintext credentials could be snooped, a MITM attack is really not such a far stretch. In my book the answer starts with, "No, the transfer is not secure. While the credentials are encrypted in transit, you can not be sure of who you are sending them to." – trognanders Mar 20 '14 at 23:53
  • I rephrased my answer a little bit, so it isn't as definitive about the security of these login transactions. Nevertheless, I think what the author intended here was to ask, whether the credentials would be sent out in the clear everytime, not only in cases where you are dealing with MitM. But you are right of course, that it wouldn't be that hard to pull off such an attack at an open Wi-Fi spot or something like this. – Karol Babioch Mar 20 '14 at 23:59
  • I like that answer more, it shows why people think it is secure, and quickly gets to the hidden danger. +1 – trognanders Mar 21 '14 at 00:02
  • Thanks, it was your input leading to this version, so clap yourself on the back ;). – Karol Babioch Mar 21 '14 at 00:05
  • SPDY (over mandatory SSL), means that indirectly SSL can facilitate a significant performance increase / reduction in server resources. –  Oct 29 '14 at 16:01
0

If you take a look at the form posting your login details you will see the following:

action="https://corsair.secure.force.com/SiteLogin?refURL=http%3A%2F%2Fcorsair.force.com%2F

This action is in fact posted over SSL/TLS. In an ideal world, the whole site is SSL. Currently, for the site in question, the login details are posted over a secure channel.

An attack vector could be a MiTM (man-in-the-middle) attack. For example, when you hit the login page, they could inject another action into the form element.

To answer the question, SSL provides the benefit that data transmitted cannot be viewed or tampered with by a 3rd party. SSL on a site after the login crediential were passed would still provide the above security measures. Obviously your credentials would now be known to an attacker, who could then log in as you.

CtrlDot
  • 472
  • 2
  • 6