In part 1 of my LUA series, I mentioned a virus that modified the HOSTS file on a PC. This meant that each time someone tried to connect to their banking website, they actually went to a fake website instead, even though they’d typed in the correct URL. This could also be a problem if your DNS server gets compromised, or if someone reconfigures your wireless router so that you use a rogue DNS server.
One way to protect yourself is to use https. If you know the correct address for the website, and you see a padlock in the address bar, you can be confident that this is the real site. This isn’t an absolute guarantee, e.g. if your PC is infected by a virus then it could add some self-signed certificates to your trusted store. However, it’s certainly a step in the right direction. Unfortunately, lots of banks haven’t quite grasped this concept.
PayPal are a shining example of how to do this right. If you go to:
then you automatically get redirected to:
You can access the secure site directly, and it has a green bar for “Extended Validation” (EV).
HSBC have two versions of their website:
Again, the secure site uses EV.
Halifax have two versions of their website:
They don’t use EV (so the address bar is white rather than green), but I think a standard certificate is good enough for now.
Alliance & Leicester have two versions of their website:
The secure site uses EV, but I get a warning message because not all of the content is delivered using https. If you choose to just view the secure content, the address bar is green. If you choose to view everything, you don’t get a padlock at all.
Lloyds TSB have their main website here:
However, changing “http” to “https” doesn’t work:
I get an error, because the certificate was issued to “secure.lloydstsb.com”. Even if I continue anyway, I can’t see the site (“page not found”). Similarly, this site doesn’t work either:
They do in fact have a secure login site, which is here:
It’s not obvious, but it’s something you could plausibly remember and type in.
Barclays have two versions of their website:
Like Alliance & Leicester, you get a warning message about the insecure content. Also, this is a slightly odd address for the website. The more obvious addresses would be:
These both redirect you to the http site. (It would obviously be better for the second one to redirect you to the https site.)
Nationwide only offer an insecure site:
The equivalent secure site simply doesn’t exist:
They do offer a secure site for online banking, but it’s a bit of a cryptic address:
Frankly, if I saw that in an email then I’d assume it was a phishing site.
The Royal Bank of Scotland offer a normal version of their website:
You can also go to the secure version:
However, this redirects you back to the insecure version! At this point, I think there’s a fine line between stupidity and malice; they’re going out of their way to stop people from using a secure connection. As the lolcats would say, “Ur doin it wrong!” The interesting thing is that they will let you use a secure connection when they advertise their security software:
They also have a separate site to login to online banking (which uses EV):
NatWest are pretty similar to RBS, presumably because they’re both part of “The Royal Bank of Scotland Group Plc”. Again, they have a normal site:
But their secure site just redirects you back to the insecure version:
As with RBS, they offer a secure page to plug the Rapport software:
I don’t know whether that software is any good, but I think they ought to get their own house in order before they ask me to reconfigure my PC. Their login page for online banking is here (using EV):
(Presumably that’s an acronym for NatWest OnLine Banking.)
The Co-Operative Bank have a good reputation for high moral standards, and I’ve considered moving my accounts over to them. Sadly, they’re a bit lacking in technical skills. Like RBS and NatWest, they have a normal website, and a secure site that just redirects back to the insecure one:
They do offer a secure login page, but it’s a really clunky address:
With most banks, I’ve been able to simplify the address by going to the root. In this case, that would be:
Unfortunately, that just redirects me back to the insecure version of the main site.
Santander are similar to the Co-Op. They have two versions of their website, but the secure version redirects you to the insecure version:
They have a secure login page, but the address is even worse than the Co-Op’s:
The issue here is that Abbey National rebranded themselves as Santander. So, if you were an Abbey National customer then you would have been bombarded with information telling you about the upcoming change (e.g. leaflets with your monthly statement). However, suppose that you are a brand new Santander customer; should you be concerned that a completely different website (abbeynational.co.uk) is asking for your bank password? Or should you be expected to research the corporate history when you open a bank account so that you’ll be familiar with their past names? I don’t think that either of those are reasonable options, so this login page earns them the bottom spot on my list.
Looking at the first section of the Co-Op and Santander URLs (“welcome27” and “myonlineaccounts2“), I’d guess that those URLs are subject to change, i.e. they expect you to get there from the insecure site, not to bookmark them. They may well do some kind of “load balancing”, e.g. if they have 27 servers for the Co-Op site then they might redirect you to a different one each time.
Back in 2005, I wrote about code signing certificates, and I said:
“Basically, before you run an application, there are two questions you should ask:
a) Do I trust the person/company who wrote it?
b) Am I sure that they did actually write it (and that nobody has tampered with it since)?
Code signing only addresses the second question, not the first. So, it’s just a part of the overall solution, but it is a necessary part.”
For websites, there are two similar questions:
1) Is the domain name correct?
2) Does it have an SSL certificate (i.e. is there a padlock)?
Again, you need to be able to answer “Yes” to both questions; on their own, each question is necessary but not sufficient.
Ideally, my advice would be: “Always type ‘https’ at the start of the address, and make sure that you see the padlock. If you don’t see the padlock, don’t type in your password.” So, for HSBC or PayPal, that’s easy. For banks like the the Co-op, I have to say “Go to the insecure site, then follow the link to the secure site (with the padlock). Look closely at the address of the website, and make sure that it matches what you’d expect it to be”. That’s a harder skill to learn.
So, suppose that someone wanted to steal your bank account details. They could set up an exact copy of the (insecure) website on their own server, and attract visitors through DNS poisoning or modified HOSTS records. At that point, even if you avoid clicking links in “phishing” emails and rely on typing the address or using a bookmark, you would still end up at their fake site.
The fake site could then redirect you to a fake login page, and it would be hard to spot the difference. The fake login page could still have a valid SSL certificate (i.e. it would display a padlock), but that only proves that you’re really at the fake website! For instance, I see that some enterprising company has registered the bank.com domain; if they were malicious (or got hacked), it would be pretty simple to set up convincing sub-sites, e.g.
The solution is to go directly to the bank’s secure website, using an address which you know to be correct. That way, even if someone can redirect you to the wrong website, they won’t have a trusted certificate for that domain, and you’ll get an error message warning you not to go any further. My concern is that banks are currently training their customers to do it the wrong way, effectively saying “Come to our insecure site, then we’ll send you to the correct secure site, and don’t worry about it if the address looks weird.”