https and business name and locality in the Extended Validation certificate look OK, too.A person who turns to me for technical advice was logging in to government service using banking credentials for a bank called Handelsbanken. However, the page that was asking for the Handelsbanken login credentials was not served from https://*.handelsbanken.fi/! After investigating what was going on, I decided to review how other banks in Finland handle this. Here are my findings.
For TL;DR, you can skip ahead to the Handelsbanken case.
Foreign readers might be wondering what banking credentials have to do with government services in the first place. In Finland, early on the government decided that they need to have a way for strongly identifying citizens for government online services. The mechanism they chose was provisioning an SSL client certificate (and an S/MIME certificate, yes, with government-issued private keys) on a chip on every goverment ID card issued. This, of course, was a terrible idea, because it combined usability and server-side deployment problems of client certificates with the device-dependence and driver problems of smartcards. Fortunately, the whole thing flopped and Finland didn’t become another South Korea stuck with a crypto solution that at some point in time looked high tech.
Meanwhile, the banks had had to come up with something that actually works for online banking. And online banking initially meant modem or telnet terminal connections, so the banks came up with a system that’s reasonably secure against fraudulent transactions even when someone is eavesdropping on an unencrypted connection. The solution was to provision lists of one-time-use passcodes to users on paper and require a code both for login and for authorizing transactions.
Once it was clear that the government’s smart card initiative was a complete failure, everyone has to be a customer of at least one bank anyway, banks had had to check the identity of their customers already and the banks already had an authentication mechanism stronger than plain passwords, it became clear that the path of least resistance would be having the banks perform the identify provider (IdP) function with government sites as relying parties (RP).
To avoid an M × N matrix of relationships, instead of the government services using the bank IdPs directly, there are a couple of aggregator IdPs: tunnistus.fi and tunnistus.suomi.fi. Thus, a site that requires strong authentication acts as an RP for an aggregator IdP and the aggregator IdP acts as an RP for the bank IdP of the user’s choice. The user chooses which bank IdP to use on the aggregator IdP site and gets navigated to the bank IdP. That is, if all goes to plan, the form that asks for bank login credentials is hosted by the bank and then the user gets redirected back to the aggregator IdP and then back to the original RP.
First, let’s look at how this stuff is supposed to work by comparing the banking login pages for clueful banks with their IdP pages. (Note that there is a third case where a merchant redirects the user to the user’s bank for payment authorization as part of an e-commerce flow. While it would be interesting to compare that case as well, I was too lazy to do that at this time.)
https and business name and locality in the Extended Validation certificate look OK, too.
tapiola.fi as opposed to lähitapiola.fi or lahitapiola.fi), but that’s OK, since the bank is reachable via the new domains, too, and the old name is familiar to customers anyway.
The bank’s front page is available from both ålandsbanken.fi and alandsbanken.fi. Proceeding from either to the banking login takes you to the ASCII-safe domain.
Osuuspankki is one of the three banks whose front page redirects to https if accessed using a plain http URL and whose front page is also the Web banking login page, so that the user doesn’t need to navigate to somewhere else. Thumbs up to Osuuspankki for using their front page for login. Still, there’s a slight problem:
osuuspankki.fi in the location bar, you get redirected to www.op.fi. This is the only case where the domain of the banking site is an abbreviation instead of being unambiguously the name of the bank followed by .fi. Since the abbreviation is well-known and the Extended Validation certificate information shows the full name of the bank, this shouldn’t be a problem, since you are supposed to know the bank has merged with an insurance company called Pohjola, except…
osuuspankki.fi in addition to the usual op.fi in case you are used to seeing only the latter.Nordea’s predecessors pioneered online banking in Finland (I started Internet banking with them using telnet before there was Web banking) and they have been pretty clueful about Internet banking. Yet, they have a minor issue with their IdP:
nordea.fi, except…
This is a great demonstration of why Extended Validation doesn’t provide real security benefits and is mainly a price discrimination mechanism that allows certificate authorities to make more money when selling to more wealthy customers. When a site uses EV and everything is OK (i.e. there is no attack going on), the user sees the green EV bar. When something is wrong, the user doesn’t see it. Therefore, as a security mechanism, EV relies on the user remembering which sites are supposed to have EV certificates. This puts a lot of faith in the user’s ability to track these things. Browsers won’t do it for the user. On the contrary, they are happy to treat EV https://example.com/ and DV https://example.com/ as the Same Origin and send cookies obtained from EV https://example.com/ to DV https://example.com/.
So even if sites that deploy EV did it consistently, EV would be dubious as a security mechanism. I say that Nordea’s use of a DV certificate make their EV certificate worse than useless, because if the user is actually paying attention the way the security model of EV expects the user to do, the user should think that the DV certificate of the IdP is fraudulent and there is an attack going on. Since the DV certificate is legitimate the security model of EV causes this situation only to make the user worried when there is no attack going on.
Danske Bank (formerly Sampo Pankki) is infamous for training their users to allow on-demand native code to be executed using a Java applet with JNI libraries. Therefore, it would be surprising if they didn’t have any issues. And indeed, they do:
http URL for the favicon.
Now let’s get to the case that inspired me to write this:
https: check. EV: check. Whoa! What? This isn’t handelsbanken.fi! What’s going on?The form that asks for the login credentials is not on the bank’s domain. That’s not how this stuff is supposed to work! Note that the user didn’t arrive on this page by navigating from handelsbanken.fi. Instead, the user navigated to the government site, got passed on to an aggregator IdP site and then navigated to this page from there by selecting the logo of the bank. That is, as far as the Web security model goes, the user hasn’t seen any proof of affiliation with handelsbanken.fi in the trustworthy part of the browser user interface. What is this Samlink company anyway? It’s not a household name that a user could reasonably be expected to recognize. And even if it was, it’s not Handelsbanken.
The text on the page (visible right under the identity pop-up that’s part of the trustworthy browser UI) gives a hint of what Samlink might be. It looks like Samlink is probably Handelsbanken’s software supplier. However, the text on the page is not a reliable indication of affiliation. For example, this page has the word Handelsbanken on it and is even served using https, but you’d be a fool to think that hsivonen.fi was affiliated with Handelsbanken.
A quick browsing around suggested that Samlink indeed is a company that provides Web banking software. Even though it was extremely probable that there was no phishing attack going on, I still chose to call Handelsbanken to make sure and to complain.
The person who took my call confirmed that Samlink is Handelsbanken’s software provider. I opined that having an arrangement where the user is supposed to enter the banking credentials on a site other than the bank’s own is totally inappropriate and irresponsible. I also think it’s absolutely inexcusable. Over the phone, we walked through the steps together to get to the IdP form. The person I was talking with pointed out to me Handelsbanken’s copyright notice on the IdP form. I pointed out that a phishing scammer could easily put that kind of text on a fraudulent page. The person took my feedback and my phone number and said that they would get back to me.
I think it is terrible that a bank puts their users in a situation that teaches the users that it is sometimes okay to enter banking credentials on a page whose domain does not match the domain of the bank. This sort of thing undermines all efforts to teach users how to be safe on the Web. Even though there was no attack going on in this case, now the users have to judge whether non-bank domains are legitimate or attack sites. Instead, the teachable message should be that you never ever enter your login credentials (bank or otherwise) for one site into a form hosted on another site.
This is similar to Nordea letting their certificate expire in June—effectively training their users to click through certificate errors—and then saying it didn’t cause a security threat.
If you’re in a bank—or any site—don’t train your users to treat scenarios that look the way an attack would look like as business as usual! How are users supposed to recognize real attacks when they are taught to that attack-looking situations are sometimes normal?
If you thought it can’t get any worse, it does get even worse. The last three minor banks, Aktia, POP Pankki and Säästöpankki, the last of which isn’t one bank but an association of tiny co-branded banks, have their own identities for Web banking, but for IdP purposes, they all defer to Samlink on a single login page that appears to take credentials from any of the three!
https for their front page, which is also directly the login page. Thumbs up for this. Also, kudos for not flocking to Extended Validation which, as noted above, has dubious security value.
Early on, I said that things are working the way they should with some banks. Actually, none of the Finnish banks have a proper TLS configuration. None of them use HSTS and, therefore, are vulnerable to the sslstrip attack (see from slide 51 onwards). Also, most of them use the RC4 cipher, which is so bad that Microsoft took special steps to make IE11 avoid it, and all of them fail at forward secrecy. Here are links to Qualys’ report for each server for your convenience. It’s not a pretty sight. (See the section Protocol Details near the bottom.)