"Secure" bank logins?
Friday, 2. June 2006, 18:06:42
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 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.
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?
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?
WIDGETIZE
burnout426 # 2. June 2006, 18:45
The 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.
yngve # 2. June 2006, 20:24
Andrew Gregory # 3. June 2006, 04:53
feldgendler # 5. June 2006, 03:23
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.
yngve # 5. June 2006, 10:40
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.
scipio # 8. June 2006, 20:11
Such a field would be a perfect place for the security warnings discussed in this blog post.
feldgendler # 10. June 2006, 05:58
scipio # 10. June 2006, 09:29
davidsickmiller # 19. June 2006, 19:25
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.
yngve # 21. June 2006, 01:40
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.
Rijk # 22. June 2006, 11:52
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?
yngve # 22. June 2006, 16:46
burnout426 # 22. June 2006, 20:44
davidsickmiller # 23. June 2006, 16:55
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.
yngve # 23. June 2006, 23:25
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.