Banks and https
Here's what happens when you go to the web pages of some large US banks, and what happens when you try changing the homepage URL from "http" to "https" or vice versa.
| Bank | http | https |
|---|---|---|
| Bank One | Insecure login form. | Works. |
| Wells Fargo | Insecure login form. | Works. |
| Wachovia | Insecure login form. | Works. |
| Bank of America | Insecure login form. | Redirects to http. |
| Washington Mutual | Insecure login form. | Redirects to http. |
| US Bank | Insecure login form. | Error: Connection closed. |
| Citibank | Link to secure login form at "web.da-us.citibank.com". | Error: 404. |
| HSBC | Link to secure login form at "www.ebank.us.hsbc.com". | Certificate hostname mismatch. |
| Suntrust | Redirects to https. | Works. |
Most of these banks make Critical SSL/TLS Mistake #1, having the login form be http and only submit to https. This protects against passive attacks, but does not protect against man-in-the-middle attacks. An attacker who can mount a passive attack can usually mount a man-in-the-middle attack with only a little more work, so these banks are barely more secure than sites that do not use https at all.
Of the banks that use https login forms at all, many make two smaller mistakes: their main page is http, which invites http links and bookmarks, and their login forms have long hostnames like "web.da-us.citibank.com", which are harder for users to verify than e.g. "www.citibank.com" or "citibank.com".
Many of the largest targets for financial fraud in the US are only defending themselves against passive attacks. Do they believe authenticated encryption isn't important in the US? Aren't these the same banks that blackmailed Mozilla developers into adding two of its most-hated features, "autocomplete=off" and "Cache-Control: no-store", claiming that any browser without these features was not secure enough for use on their sites? Banks in the US are heavily regulated, so why aren't they mandated to use https correctly?
Users either don't look for the lock icon at all, or can be tricked by the combination of a lock image and a statement in the page like "The moment you click Sign In and before your ID and passcode leave your computer, we encrypt them using Secure Sockets Layer (SSL) technology." Why is that? What can be done? What should be done?
May 28th, 2005 at 7:07 pm
I’m a us bank customer, and they JUST put their login form on their front page. It used to be a link to a secure page. I just use a bookmark to their secure logon page that I use.
May 28th, 2005 at 7:32 pm
Citibanks WFM. Selecting Sign on to bank accounts successfully redirected me to the https site. All of the login links I get from them are https.
May 28th, 2005 at 7:36 pm
I contacted Wachovia, since they’re one of my banks. We’ll see how far I get.
May 28th, 2005 at 7:47 pm
Bank of America has an http sign in on their front page, but if you click “Sign In” > “Sign In”, you get to an https login page that then keeps you at https while logged in. Of course, if they got rid of the http sign in, then people would complain that it’s too hard.
May 28th, 2005 at 9:06 pm
It would have been interesting to add some examples of banks that do get it right. For example, E*Trade (which is both a brokerage and bank) appears to be doing the right thing: http://www.etrade.com redirects to an https page (either an E*Trade worldwide page or a country-specific page) with login form. In fact, it appears that all of E*Trade’s web site is SSL-protected; I couldn’t find a case where you could access an E*Trade page as HTTP-only. (Incidentally, E*Trade also offers its customers the option of using an RSA SecurID device for login.)
May 28th, 2005 at 10:23 pm
Maybe this is an issue for:
Technology Evangelism – mozilla.org http://www.mozilla.org/projects/tech-evangelism/
I know that I was able to (with help) overturn MBNA’s bad browser sniffer from bugzilla Bug 227992
( MBNA Net Access site say I “must upgrade to Netscape 6.2 or higher” – https://bugzilla.mozilla.org/show_bug.cgi?id=227992 )
May 29th, 2005 at 6:40 am
“What can be done? What should be done?”
In this case, I’m not sure there is anything that can be done except site education, which may require them learning the hard way.
I can’t immediately see anything we can change in the browser to fix this.
May 29th, 2005 at 6:15 pm
ANZ http://www.anz.com/ (one of the big 4 banks in Australia) gets it right, with a seperate https login page linked from the http homepage. Unfortunately no https login form at http://www.anz.com/ but still a link to the login page.
Wouldn’t there still be an issue with MITM attack with a http homepage linking to a https login page?? Not sure if anything can be done about that case.
May 30th, 2005 at 9:29 am
Drat. My bank, Fleet, has a straight link off their front page to the Personal Banking page, whch is all HTTPS. Bank of America just bought them up. I do hope that when they migrate us to their online system in ~July, they will let us keep the same level of security we’ve been enjoying. I really hope they take a hint from Fleet, and keep the quality up over here on the East Coast (and maybe pass it around a bit). I’m very happy with how Fleet (and NatWest before that) treats me, but I have ‘iffy’ feelings about Bank of America.
Thanks for the summary – good information is the key to having some kind of defense against phishing, and other bits of seedy Internet activity.
May 30th, 2005 at 10:56 am
So, what really is the best practice here? I work at a web consultancy where two of our financial industry clients are facing this issue. They are insistent on having a log-in form on their homepage. The form would do https posts to several different and separate services sites they use for their customers. We are building the marketing site. If we recommend they serve the whole site (which is 99.9% marketing material – all their online forms would be https as it is) via SSL, they lose some visitors with outdated browsers (minimal, i know, but they are concerned) plus they lose compatibility with some search engines (MSN does not currently support SSL sites, although I’d be surprised if that lasts long as Google and Yahoo do). They seem to be opposed to just having the home page be HTTPS, partially due to the search engine and browser compatibility issue. They are actually more willing to deliver the entire site via SSL than to do a “mixed site” where only pages that have forms on them are SSL.
My question is – if we are fearing a man-in-the-middle attack, why do we only fear this for login pages? Couldn’t ANY response be intercepted and altered to add a malicious form, a redirect, etc? Even if we were to redirect a user who tries to visit the http homepage to an https homepage, couldn’t that redirect response itself be intercepted and altered? I’m no security expert, but it seems like you’d have to be 100% SSL and have NO http responses at all to avoid this entirely…
May 30th, 2005 at 2:53 pm
Amazingly for once it seems the major UK banks get it right! (NatWest, Barclays, Alliance & Leicester, Abbey etc)
May 30th, 2005 at 3:44 pm
“My question is – if we are fearing a man-in-the-middle attack, why do we only fear this for login pages?”
It’s particularly bad for login pages because the attacker can redirect the form target to his machine and capture raw usernames and passwords rather than e.g. session tokens, which should be IP-range locked.
“Even if we were to redirect a user who tries to visit the http homepage to an https homepage, couldn’t that redirect response itself be intercepted and altered?”
The HTTPS response could either come from your bank, in which case it’s secure because of SSL, or from another site, in which case the URL bar would change to reflect the change of location.
May 30th, 2005 at 7:00 pm
Right – https responses are safe, but couldn’t a savvy man-in-middle attacker just insert log-in forms or other changes to any http response, and make the page look like a legit page of the site in question?
May 30th, 2005 at 9:13 pm
Interesting. I had assumed the reasons were related to speed or server costs.
For the search engine issue, I think you should give MSN (and maybe a few others) the https page over http. Technically, this is cloaking: you’re giving browsers one thing (a redirect to https) and search engines another thing (a web page). But since this type of cloaking is not intented to mislead either users or the search engine, hopefully it won’t get you kicked out of MSN’s index. You might want to contact MSN beforehand so they’ll understand why you’re cloaking.
Supporting ancient browsers would require you to print http URLs, which I think is a bad idea (see below). If you must support ancient browsers, I guess you could give them content instead of a redirect on http and use “Vary: User-Agent” to keep caching proxies from getting confused.
If an attacker has compromised a router between a user and your site, he can make http://www.mybank.tld/ appear to be whatever he wants even if your site rejects http requests entirely. So you should try to (1) encourage users to connect using https initially and (2) educate users against both phishing and man-in-the-middle attacks.
1. Encourage users to connect using https initially.
In advertising and instructions, always give the full URL: https://www.mybank.tld/. Consider making the ‘s’ bold. Depending on how important it is to train users to connect using https initially, you could then:
(i) Make http://www.mybank.tld/ redirect to https://www.mybank.tld/. This will get users to bookmark https, but it might not get them in the habit of typing https, and some sites will link to http. Also, for reasons I do not understand, this might not get Google to link to https.
(ii) Make http://www.mybank.tld/ be short page that says “For your security, always connect to MyBank using https://www.mybank.tld/.” It could redirect after 3 seconds, or it could require users to click a link, or it could even require users to retype the URL.
2. Educate users against both phishing and man-in-the-middle attacks.
In a well-executed phishing attack, the email will be crafted so the link in the email looks like it goes to an address that is owned by your bank. When the link is clicked, it will take the user to an https page owned or controlled by the attacker. The page will have a hostname like http://www.online-banking-mybank.tld or http://www.mybank.tld.bankingonline.com, which looks to an untrained user like it could be a hostname of your bank.
In a well-executed man-in-the-middle attack, http://www.mybank.tld/ will appear to victims pretty much like Bank of America appears now: a login form on the front page, a fake lock icon image in the page, and a message saying that their financial information will be encrypted as soon as they click Submit.
Your goal is to keep most users from entering their passwords when this happens. I think the best way is to include a security message in the physical instructions for online banking as well as on the site. It could look like this:
“We will never ask for your password except from a URL that begins with https://www.mybank.tld/. Pay special attention that the protocol is https, which indicates that it is encrypted and authenticated, and to the slash immediately after http://www.mybank.tld, which indicates the end of the hostname part of the URL. Be especially careful when checking the URL if you arrive by clicking a link in an email message, because fraudsters frequently forge emails from banks asking you to click a link to log into your bank, and the link takes you to a site owned by the fraudster.”
You might tailor the message for users of different browsers: instruct Firefox users to look at the status bar rather than the address bar to determine the hostname (web pages can turn off and then spoof the address bar), instruct Internet Explorer and Firefox users to always maximize a window before checking the URL, suggest that Internet Explorer users switch to a browser with fewer security holes, instruct Opera users to look for a yellow box on the right of the address bar, etc.
Also consider linking to a page that explains some of the technical details, so that users who access multiple secure sites will have the choice of understanding URL security rather than memorizing rules from each secure site they use. This page should explain the difference between http and https, how to parse a hostname out of a URL, and how to figure whether a given hostname is part of mybank.tld (e.g. banking.mybank.tld, but not mybank.tld.banking.tld or banking-mybank.tld). I think diagrams could help for explaining each of these concepts. The page could also give examples of attacks so users will understand why they have to check for everything they have to check for.
May 31st, 2005 at 6:34 am
Jesse, thanks for the detailed response. That is what I needed to know.
Yes, their IT department is somewhat agnostic on the issue because whatever is decided, it’s a marketing initiative and therefore costs would be covered by marketing’s budget. Some parties are pushing for full HTTPS based on recent industry recommendations, and marketing is fighting it based on usability, search engine listings, etc. You make a good point about delivering content to search engines via http and redirects to browsers. I don’t know if the client would fund that, but it’s good to know as an option.
May 31st, 2005 at 12:56 pm
What are the usability arguments against using full HTTPS?
June 1st, 2005 at 8:55 am
I contacted Bank of America and included a link to this post, but I received a very generic response that’s filled with apparently false information:
June 2nd, 2005 at 11:16 am
http://digg.com/security/Jesse_Ruderman_-_Banks_and_https
June 3rd, 2005 at 7:18 am
I’m still not convinced about this attack in anything other than a theoretical one. If we’re assuming the attacker can modify the http stream, then it’s just as trivial to redirect all requests for the “secure” login form to a totally alternate phishing site, which uses all the typical web browser tricks to disguise the page, that fools a large percentage of users.
Even more, if the attacker controls the the network connection, then they can attack at the DNS layer, which is not encrypted. So even if you turn off your http site, demand that customers always type in the URL or visit from a bookmark straight to the https site first, the attacker can return an arbitrary IP and do the same tricks, just as easily.
None of this is really very secure in the end, and the difference in security between a non-https and an https login form is pretty insubstantial. If you want to be safe, always check the certificate and verify the fingerprint, and don’t disable the “you are posting an insecure form” message. I think we can agree that trying to educate users to do this in general is about impossible on a large scale.
So yes, its risky, but I don’t think its any riskier than having an online banking site at all.
June 3rd, 2005 at 4:03 pm
Rob, I don’t understand most of your comment. Here’s my understanding of what is secure and what isn’t:
http: not secure against passive attacks, because the attacker can see sensitive information that is transmitted without encryption.
http with a form that submits to https: secure against passive attacks because the sensitive information is encrypted. not secure against man-in-the-middle attacks, because the attacker can modify the http page to point to the attacker’s own http(s) server or add keylogging JavaScript.
https: secure against man-in-the-middle attacks, even if DNS is compromised, because the certificate is checked against the hostname rather than the ip address.
Why do you think it is important (or even useful) to check the certificate manually? What are you verifying the fingerprint against?
Keeping the “you are posting an insecure form” message enabled does not improve security. Instead, you should look for a lock icon (and the correct site) before typing sensitive information. Form submission isn’t the only way for information you type to go to an attacker.
June 3rd, 2005 at 10:42 pm
You’re right, I got ahead of myself a bit. An all https connection provides some protection against DNS compromise through the hostname check, although all that results in a security warning. I think the state of user education is such that many people would just ignore such a warning, but it’s better than nothing (too early in the morning for me apparently. :-))
That however, assumes that the user initiates the request via https and the entire “session” stays https the whole time. If there are -any- http requests before the http one, the active attacker can modify those at their leisure to direct the user wherever they like. Then you are dependent on the user’s knowledge level about what is secure and what isn’t for security. Since this is exactly how phishing attacks look and work, and they are obviously lucrative enough for people to continue, I’d say if the attacker gets this far they’ve won.
How many businesses are going to accept refusing connections on http://www.bankname.com? You can’t put any redirect or link to the secure site there because the attacker will use that as a wedge to keep the end user from ever seeing the site. Unless something major changes, if the user types in http://www.bankname.com and gets “connection refused”, I don’t think that’s going to fly.
I’ll grant that it’s slightly easier to execute the insert-keysniffing-javascript or https->http modification, but as the phishers have demonstrated, it’s still lucrative and workable to do the other. Making the login page https just delays the inevitable shift in tactics by a month or two. And as pointed out, most of these sites have a secure login page available a an option, but how are you getting there? From a link on an http page? In that case an active attacker never even allows you to get to the banks website. You’re on their server, and it’s up to you to figure out how to figure that out.
Checking the certificate would verify that your connection is https, and that you are connected to the website you think you are, assuming you had the fingerprint from some secure offline means. But how many banks have a 1-800 number where you can call and get their certificate fingerprint? How many even have infrastructures that just use one single certificate. Phishers have been wildly successful through javascript image maniuplation at faking secure sites. Modifying the URL to appear correct when it is not, adding a lock icon to the status bar. These vary in effectiveness, but it’s proven that they work well enough to fleece at least some people. Going to the actual certificate and verifying that everything looks to be in order avoids those attacks.
In the end, all of these scenarios require active interference with the network stream. Which means it’s extremely unlikely that anyone other than someone on a mid to small sized network (university most likely, internet cafe, etc.) is going to be be able to pull them off (if you’re good enough to hack some giant ISP’s core router and insert efficient enough code to modify http streams without getting noticed then stealing online banking ID’s probably isn’t all that interesting to you). In those scenarios, it would probably be a lot easier to just install a keysniffer on a bunch of the systems in question. Trojan horse/worm/virus keysniffers are much more common, go around all of these protections, and are responsible for much of the high-profile individual attacks taking place now (and the ones driving actual lawsuits against the banks).
I’m not saying it’s not riskier. It’s just that in the grand scheme of the threat tree, it’s pretty far down on the list of likely attacks. If you are worried about it, then your only safe recourse is to memorize your banks https login url and always type it straight into a known-secure computer. But how can we ever get end users to get to that point?
June 3rd, 2005 at 11:54 pm
Sorry to soapbox; there is a lot we agree on here. Particularly the messaging. The lock icons and copy about “secure from the moment you hit the login button” are ill-concieved at best, and at times outright misleading. Granted, I don’t know what the right answer is given that you need a high level of knowledge to understand the risks. I’m always more a fan of education and honesty over trying to play to the lowest common denominator and keep people in the dark.
June 15th, 2005 at 1:29 am
Curious pointed out: “The easist way to find the https login for a bank is to submit a badlogin, this will often give you a login page that is https”
June 24th, 2005 at 8:14 am
Concerning Washington Mutual: If you go through their homepage, it is unsecure. However if you click “My Accounts” you will get a secure login prompt.
July 20th, 2005 at 7:57 pm
Jesse,
Did you receive a reply to your question: “What are the usability arguments against using full HTTPS?” Faruk.
July 20th, 2005 at 9:30 pm
Faruk: no, I did not.
August 23rd, 2005 at 3:21 pm
Online Banking with Bank of America
Online banking websites like Bank of America should use SSL login pages, as non-SSL pages are not secure.
…