Are login boxes on http:// pages secure?
December 1, 2009 6:39 PM   Subscribe

Some major websites--such as Facebook, Vox and others (but not Metafilter!)--have users enter username & password on an http page rather than an https page. Is this as secure as logging in via https:// and if so, why?
posted by mono blanco to Computers & Internet (18 answers total) 3 users marked this as a favorite
 
They may or may not be secure; it depends on what URL the form submits to. For example, on Facebook, the Login form is thus: <form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">, so your login information is being sent securely. Unfortunately for the user, there's no way to tell short of digging through the page source whether a given form submits to an http or https URL.
posted by 0xFCAF at 6:46 PM on December 1, 2009 [2 favorites]


It's the protocol used to post the login information to the server that matters, not the protocol used to fetch the HTML for the login form.
posted by effbot at 6:48 PM on December 1, 2009 [1 favorite]


For a high-volume site, the amount of overhead saved by serving an http page for logged-out-or-not-even-members pages rather than an https one is likely significant.
The actual submit button, as others have said, takes you through the https protocol.
posted by jozxyqk at 7:01 PM on December 1, 2009


In theory, if the login page itself is accessed via https, this should protect you against attempts to redirect your connection to a fake login page on another server, or to intercept your connection and serve up a slightly modified version of the login page. Either of these thing could be done in an attempt to capture your login credentials.

When you make an https connection, the server you're connecting to has provided a certificate to identify itself, and that certificate is signed by a certifying authority that your browser has already been configured to trust. A fake site or a man-in-the-middle isn't supposed to be able to provide an acceptable certificate, and with https the connection is encrypted, so someone between you and the site can't successfully modify the login page in transit either.

Of course in the real world, the security this provides is only as good as the difficulty of obtaining a fraudulent SSL certificate, the security of the authentication and encryption mechanisms themselves, and the willingness of the user to click "continue anyway" when told the SSL certificate isn't right somehow.
posted by FishBike at 7:06 PM on December 1, 2009


They may or may not be secure; it depends on what URL the form submits to. For example, on Facebook, the Login form is thus: , so your login information is being sent securely. Unfortunately for the user, there's no way to tell short of digging through the page source whether a given form submits to an http or https URL.

This is a common misconception. It is not secure just because the form action is to a secure page. Remember, nothing on an HTTP page can be trusted, including that little 's' after 'http'.
posted by odinsdream at 7:13 PM on December 1, 2009 [2 favorites]


odin, are you claiming that HTTPS only works properly for GET requests?
posted by effbot at 7:35 PM on December 1, 2009


It is not secure just because the form action is to a secure page. Remember, nothing on an HTTP page can be trusted, including that little 's' after 'http'.

This is slightly inaccurate although your point is valid. Yes, it is true that someone could manipulate an HTTP page before it gets to you and strip the "S" off the HTTPS form submission URL. However, you can detect that by viewing the source code once the page is in your browser. If you read the source code and see that the form submission URL is indeed to an HTTPS address (and no other code elsewhere on the page is manipulating that URL dynamically) then you can be sure that the form will submit securely. But of course 99% of users don't do this, and it is prone to error (e.g., it would be pretty easy for the attacker to inject some obfuscated JavaScript into the page that would change the HTTPS submission URL to something else after you've clicked the submit button).
posted by Nothlit at 7:37 PM on December 1, 2009


Nothlit; yes, that's exactly my point. Any number of JS files included in the page could make the change just before a click. It's very common for developers to use JS files hosted off-site, served via HTTP. Any of these could be replaced by a malicious user with additional code to alter the POST method.

From a development standpoint, it's worth absolutely nothing to use HTTPS as the form action. It's a completely empty gesture.
posted by odinsdream at 7:43 PM on December 1, 2009 [2 favorites]


In that case, odinsdream, I am in complete agreement with you. :-)

To the OP: it is possible (but not guaranteed) for a login form presented to you on an HTTP page to end up being submitted securely, but there is no guarantee of this, and you are unlikely to find out until after it's too late (i.e., after you've already submitted the form). I would not personally log into anything sensitive (email, banking, etc.) via this method.

On the other hand, it is also entirely possible for a login form presented to you on an HTTPS page to end up being submitted non-securely (HTTP) but that would most likely be an implementation error, not the result of any man-in-the-middle attack. And most browsers tend to prompt you if you are about to submit a non-secure form from a secure page, so you could cancel the submission before it goes through.

Ultimately, a form presented to you on an HTTPS page is likely to be more secure than a form presented to you on an HTTP page, and if given the option, you should always obtain the login form via HTTPS.
posted by Nothlit at 7:52 PM on December 1, 2009


I wouldn't say it's a completely empty gesture. There are many different attack scenarios. Having a https form action on a http page does thwart some of them (such as casual snooping from someone else on the same network segment with ettercap), and not others.
posted by Rhomboid at 8:35 PM on December 1, 2009


It is not secure. No.

HTTPS obscures information, yes, but more importantly for this case is that it ensures it is not altered.

The destination of the form very well may be an HTTPS location, but that is something you're hoping for when you hit "submit." If your log-in page is HTTP, then it could have been altered between the server and you. Unless you look at the source every time, then having an HTTP log-in page is about as "secure" as having no HTTPS at all. A cracker needs very little skill to set the log-in form to post cleartext to himself and steal the password, and then direct you to the real site so that you do not know anything untoward has happened.

So, don't trust pages that are not HTTPS and signed by a known certificate authority.

OTOH, if your log in page is not HTTPS, then the admins of that site probably have so little clue that your data there is vulnerable by other means already, and the log-in page may not matter a lot.
posted by cmiller at 9:24 PM on December 1, 2009


As a side note, sometimes these sites do support https, even if they don't advertise it.

https://facebook.com
posted by zippy at 10:42 PM on December 1, 2009


The question as stated is a bit naive and misses the steps that must take place correctly to be secure. The login protocol for these websites is as follows:

1. Retrieve a login form from a website, containing some fields and a destination to submit to
2. Fill in the form
3. Submit the form

Applying HTTPS to only step 3 protects the you provided in step to, but only to the destination it's submitted to. An attacker who modifies step 1 can change that destination, or include a javascript to do all sorts of nefarious things like send a copy to a second site or rewrite the form to submit to a man in the middle. There are a few DEFCON talks about HTTPS stupidity, and I recall Kaminsky talking about using Google to find bad setups like "why this page is secure" delivered over HTTP.

The counterargument to this is that HTTPS is computationally expensive, and even if you set up a completely secure chain, users will still ignore security warnings due to the great mass of documented poorly informed admins you've seen documented upthread. My own IT helpdesk regularly informs users to ignore cert warnings and I've not seen any indication this will change.
posted by pwnguin at 11:48 AM on December 2, 2009


Thanks, I understand better now. Anyway, security is analog, not digital, so my new protocol is:

a) Find out if the site has an https logon page and, if so, use it.
b) If not, do a quick source check, searching for "https" to see at least whether that group of letters appears in the neighborhood of the logon box.
c) If yes, decide whether the level of security suffices. Banking: no. Blogging: yes.
d) If no, then the site is very weird. Avoid or use a sock puppet.
posted by mono blanco at 2:04 PM on December 2, 2009


Most modern browsers will warn you when you submit login information via insecure (http) forms. I think you are being a little over paranoid.
posted by chairface at 3:50 PM on December 2, 2009


No, they will warn you if you try to submit to a http destination from a https page. They won't say a thing if both the form and the destination are http -- that practically describes 99% of all forms on the web.
posted by Rhomboid at 3:56 PM on December 2, 2009


Rhomboid: "No, they will warn you if you try to submit to a http destination from a https page. They won't say a thing if both the form and the destination are http -- that practically describes 99% of all forms on the web."

chairface is right, actually. Browsers do have the ability to warn you when you're submitting any form via http instead of https, and on most of them the warning is enabled by default. But the warning comes up so often that it's one of the first things users disable. I switched it back on in Firefox just now and it comes up every time I preview a comment here, for example.
posted by FishBike at 6:16 PM on December 2, 2009


God, it's been so long since I've used a stock browser that I forgot about that annoyance. But I still submit (no pun intended) that nobody in their right mind leaves that warning enabled, because you'd be driven batshitinsane by the amount of warnings.

Oh, I meant to also suggest:

e) Use a different password for every site, so that if one is compromised due to insecure login form it won't compromise everything else. With modern browsers remembering form fields it's not too much of a burden to remember, and just keep a text file or something listing them all.
posted by Rhomboid at 7:10 PM on December 2, 2009


« Older Can I get paid just to be somewhere for a long...   |   Gifts for my Conspiracy Theory Obsessed Friend! Newer »
This thread is closed to new comments.