George Ou over at ZDNet has recently been engaged in a one-man crusade against banks that let users log in to their on-line banking services directly from front pages with no security, for the sake of user convenience. This means that the login form is placed on a HTTP page, while submitting to an HTTPS URL.
Why is that bad?
The thing about unsecure pages is that they are … unsecure. You do not know that you are on the right website, there is no secure certificate vouching for the identity, there is no encryption and no integrity checks of the received content. That means that anyone can modify the page, in fact somebody can take over your DNS server and serve you a completely fake page, and there is no way to find out it is happening!
That the pages can undetectably be modified means that an attacker could send anything you enter into the form (such as your account name and password) to another server, and then just send you on to the real secure site, and you would be completely unaware that you were just phished.
This practice has not just irritated me for a long time. Eric Lawrence of Microsoft called it "Critical Mistake #1" in an IE Blog posting a year ago.
So what can be done about this?
Several options are available:
- Evangelism, like what George Ou is doing
- User education
- Browser security warnings
Evangelism is a long uphill battle, in particular when you are up against the "Everybody is doing it"-argument. However, there are good examples of banks who get the point, at least in Europe. Several Norwegian banks, such as Norway's largest, DNB Nor, are using SSL for their entire sites, even their public advertisements and information pages.
User education is important and one should definitely get people to look for the padlock and check other information, such as the information in Opera's security toolbar. Work is being done to make such information more readily available to users. But, as with evangelism, this is going to take time.
What can the browsers do?
There are several options available, although as far as I am aware, none of them are currently being developed, and all of them are going to annoy users and usability experts alike.
- Refuse to submit HTTP to HTTPS forms. This option is too extreme to be considered realistic. It also does not necessarily stop the attacker from getting the data.
- Warn before submitting a form from HTTP to HTTPS, similar to what we already do with HTTPS to HTTP form submits. This would require the user to click OK, and would not just be annoying, it would also help train the user in clicking OK on all dialogs. It also cannot stop the attacker from getting the data, although that problem might be avoided if the dialog was triggered when you enter the password field.
- Inform the user about the problem, e.g. with a tooltip, just as he or she places the cursor in the password field. This has the benefit of not being too annoying, and it also does not require the user to click OK in a dialog. It may be a bit too unobtrusive, but I think it could be a good starting point. Another benefit is that the user gets the warning before typing the password, which means that an attacker has not yet had an opportunity to see it. A drawback is that we cannot use this method to warn about credit card fields.
- Print a warning in the error console. This will be completely unobtrusive, but also far too invisible as most users would not see it. It could however be used in combination with the tooltip to provide more information.
- Reduce the security level of the target page. Opera is already using a "weakest link" security-level indicator which displays "level 0" if unsecure content is mixed with secure (and in 9.0 the security toolbar will be gray in such cases). In cases where a form is submitted from an unsecure page to a secure server, we could consider lowering the security level to zero for the entire document. As many people don't really look at the padlock this might be a bit too subtle, but I think it could be using in connection with some of the other suggestions.
In my opinion the most realistic way to inform the user would be to use the tooltip, in combination with the error console and the security level, as those do not annoy the user too much, while informing the user that there is a potential problem on the site.
Some of these actions, such as the warning dialogs, would not really be effective unless all the browsers implemented them, because of the inconvenience they would be causing.
A general problem is that we cannot give such warnings when the information is gathered by a Java or Flash applet.
What can you do as a user?
You can decide not to use login forms for secure services placed on unsecure servers, and to let the banks and other sites relying on sensitive information know that you want them to fix their login systems. Unless these sites get actual negative feedback on their unsecure practices, they will continue to use the convenience excuse.
What do you think?
On the front page of http://www.key.com/ they embed the https://accounts.key.com/ login page in an iframe, so when you are submitting, you’re submitting from a secure page, but it looks like you’re not unless you check the code of the page. Of course, that’s assuming you get the *real* http://www.key.com/ page. You can always go to https://accounts.key.com/ directly though and log in. The signon form on that page is in an embedded iframe though, so to get directly to the login page, you goto https://accounts.key.com/ib2/Controller?requester=signon&dev=trueThe secure iframe page that makes it look like the form is on the current http page seems better, but that’s assuming the http page is legit.Just to add:They used to have you log in with your SS# as your user name. Now, they make you define a user name other than your SS#. Plus, they’re now making you register your computer with them or you get denied access unless you use your password and then your pin number to log in.
Mixing secure and unsecure content (either way) is a problem, but an implementation of my suggestions should take the entire construction of the page into consideration, at least all the parts wrapping around the login form, not just the URL of the document containing the form.
I don’t see a problem with a warning message. An OK button would be totally inappropriate – there’s nothing OK about it! What if the buttons were “Submit INSECURE form” and “Cancel” (along with the message that nobody ever reads). Most people at least read the buttons they’re pressing.
The described attack (faking the insecure front page) is far more dangerous.No warnings will help if an attacker changes the login form so that it submits to a HTTP (not HTTPS) destination. That would be HTTP submitting to HTTP, a plain normal thing found in the Internet every day. This means that the user will be getting warnings when he is on the real site, and no warnings when on the fake site.
Feldgendler: Maybe, but the whole point of the warning is to get the on-line banks to start using a secure login page, which would neutralize that threat.And a more dangerouos takeover of an unsecure webpage is a webpage that act visibly exactly as you expect it to, but when you log in it send your details to the attacker as an (e.g.) image request just before it sends you with no visible delay to the real secure server which you expects to be sent to. OTOH you have incidents like the recent takeover of 300+ secure netbank servers. None of the approaches in my article can handle that kind of attack.
Some time ago I suggested that a different kind of status field be introduced: one which would display a certain (1-line) message until the next one was available and with the possibility to go/scroll back to previous messages. Anyone who has ever worked with AutoCAD has probably understands what I’m talking about (see bottom of screen; btw, I think AutoCAD’s implementation takes up too much space). Such a field would be a perfect place for the security warnings discussed in this blog post.
scipio: A typical AutoCAD user is very different from a typical browser user. The latter won’t look at a message until it’s pushed in his face, and even then he’ll try to ignore it.
I guess you’re right – I was thinking from a developer’s point of view. :p
There are definitely security vulnerabilities involved placing login forms on HTTP pages that submit to HTTPS pages. However, what is the solution for website developers?What if a website replaced the login form on its HTTP home page with a link to a secure login form? I would argue that this provides no additional security, since the home page (and its link to the secure login form) could be replaced with a fake version. We should keep in mind that fake versions can be done not only by hijacking DNS but with look-alike domain names.A more secure alternative would be for a company to require serving *everything* in HTTPS and train its users to check for the browser padlock.Even then, there are still some potential vulnerabilities: HTTPS pages can be vulnerable to XSS attacks. Is it possible to purchase SSL certificates for look-alike domain names?I think we should actually *encourage* form submissions to HTTPS pages, whether they come from HTTP or HTTPS pages. For starts, perhaps we could give the submit button a gold border if the form submits to HTTPS. This isn’t foolproof (a hacker could fake it with a submit image), but the idea is to gently inform users that some forms submit with security and other forms do not. This idea could be tweaked by using different visual effects (preferably something that only the browser could do) and modifying different elements (maybe the password field instead of the submit button).Another idea to encourage form submissiosn to HTTPS pages would be to always display a warning when a password field is submitted to an HTTP page. Unlike the generic insecure warning message, don’t let this warning be turned off. It should be a safe assumption that if user input shouldn’t even be displayed on the screen, it should be encrypted for submission.
David: Sensitive services, such as online banking, SHOULD ALWAYS use secure logins, from secure pages, and in fact should put their entire website on a secure server, such as what a number of banks, such as Norway’s largest, DNBNor.no, and one of the largest US banks, Wells Fargo.The problem with sensitive login formsubmit from unsecure pages, are that you do not know who wrote the page you are logging in from, and not even whether or not it is the same page that the server sent you.The benefit of having a secure login is that there are actually ways to check that you are at the right place. Yes, domain spoofing is possible, so is Cross Site Scripting exploits, but those are issues that we would have in any case, and that must be solved by other means. And their existence does not invalidate the argument that “secure” login from an unsecure page is inherently insecure.Some people have already written extensively about this problem; as an example, Mozilla’s Bob Lord has written several articles about how banks may actually contribute to phishing by this kind of unsecure logins, and the excuses they use. See http://boblord.livejournal.com/tag/phishing for more details.As for a gold submit button: Nothing, absolutely nothing, within the document view can be trusted to indicate security, as you yourselft pointed out. That is under page control, and a page can do whatever it pleases. Security indications must be within the browser chrome to be useful at all.Submitting sensitive passwords from an unsecure page is something that just should not be done. There are no valid excuses for not putting the login page on a secure server.
Hi Yngve,I just logged into my http://my.yahoo.com account, and noticed that they now only offer a login form on a http page. They used to have a link to a https variant as well. Now, they have a link to explain ‘this is secure’, and apparently use some redirection to login on https and then return to http again. Conveniently transparent, but it is also completely impossible for a normal user to check the SSL, or determine if this is even as secure as they say.Any thoughts on that?
Rijk: Not printable.
What about https://login.yahoo.com/ ?
Yngve wrote:Submitting sensitive passwords from an unsecure page is something that just should not be done. There are no valid excuses for not putting the login page on a secure server.So do you agree that submitting a form containing a password field to an HTTP url should always generate a warning, i.e. a warning that cannot be disabled? This doesn’t fix the entire problem, but it does seem to improve the situation.
I said “sensitive passwords”, which is what my post is about. Forum logins can in a way be sensitive, but not usually in the economic sense. That kind of logins can be handled separately.Preferably, I’d want to get all logins converted to Digest Authentication.
bank bank tuts…