https and shopping, for dummies

When you are using any on-line shop you are expected to hand over some personal details, including a credit card number, name, address, expiry date, code from back of card, etc.

Indeed, these are the very details that a hacker would like to use to buy things using your card. They have to be, as you are in fact buying something using your card!

One the the great things that computers can do is send that data to the merchants securely so that nobody can snoop on it on the way (not even Theresa May). This is important because your Internet traffic will go via a load of different companies to get to the end point, and you cannot be sure of trusting every individual within those companies who could have access to your data to not to be a criminal. This is even more important when not at home and using someone's wifi.

Look for the padlock

You can tell when this is happening by a padlock by the web address. This is the browser telling you it is secure, and that the other end at least matches the web address. If you click on the padlock you can get more information, and in some cases the browser will show you the legal name of the company by the padlock. What this means is that a protocol called "https" is being used.

But there are two key parts to using https  - one is the way the data is sent so that nobody can snoop on it, but the other is checking the other end is who they say they are.

This second part is very important, as the other end, the web server, does get to see all of those details you are entering. If they are not really the merchant of bank or payment company that you think you are talking to, but instead some hacker, then the padlock does not help you.

To ensure that credit card details are handled carefully, there is a whole heap of crap that retailers have to go through called PCI/DSS. It is well intentioned, but really is horrid from a technical point of view. I don't mean that it forces unnecessary levels of protection and security - most of the ideas are sensible - I mean it makes huge assumptions about the way things are done and then asks lots of technically stupid and leading questions that can be impossible to answer honestly.

However, in spite of all of this annoyance, it seems that the basic level of PCI/DSS compliance, the self assessment questionnaires, lacks a simple question about your web site...

Yes, they do require that card details are encrypted when sent, but they don't require that the previous web page - the page where you type in those details - is secure (using https).

I'll try and explain - when you are presented with a form to fill in, that form has come from a web server. When you type in those details and press the button, those details are sent to a web server, and a reply page comes back. They do not have to be the same site or use the same protocol. It is quite possible for the form asking for details to be insecure (just using http, and no padlock), but the details you send are sent using https, so secure. So yes, the details are safe from passive snooping on the Internet. Apparently this meets the PCI/DSS self assessment questionnaire and requirements.

But there are two major issues with this:

1. It trains the public that they do not have to expect the padlock when completing the details. This is very bad. It is a bit technical for someone to check if the details will be sent securely or not, and you cannot expect everyone to be that technical. It is only by the public being aware and checking at the very least that there is a padlock that hackers can be thwarted and preventing from defrauding banks.
2. It allows various types of attack that would not be possible if the form itself was secure (example below).

The attack I am talking about relates to knowing the other end is who they say their are. There are various ways to attack the bits in the middle of the Internet and even divert them (DNS attacks, DSL router attacks, ARP/ND spoofing, routing/BGP attacks, and so on). These could send the request for the web page to a hackers server instead of the merchants real web server.

Now, if https is used, the hacker cannot pretend to be the merchant or server in questions as they do not have the keys that are necessary to make the padlock appear. The browser would tell you that something is wrong.

However, if the form is just a normal, non-secure, web page, they can send an identical looking form to you. When you post the details, instead of those going securely to the merchant or the bank, they go to the hacker.

Now the hacker can even be clever, and after copying the details he can send your web browser on to the right place, a secure https web site for the bank or merchant with your details, so to you it looks the same. Indeed, he could be feeding the order to the merchant cleanly as well and allow your purchase to work perfectly with neither you, nor the merchant, knowing there is any hacking. Then, when he has lots of card details, he can use all of those card details, or sell them.

This is why it is very important to check the page you are filling in has the padlock - at least do that. There are many more checks you can do, but the most important is that simple first step.

Sadly I found a merchant that is using something called an iframe. It means you have someone else's web site in the seamlessly shown middle of your web page. In this case they have the payment company's web site in theirs, but you do not see an address bar and do not see a padlock.

So in this case you cannot tell that the data will be sent securely. You cannot tell who it is being sent to. You cannot tell the encompassing page has not been changed so that it includes some hackers page in the iframe. You promote a public acceptance of payment pages that do not show the padlock. It should not be allowed, and I hope the PCI/DSS rules are changed to stop it.

Sadly their card processing provider, Sage Pay, seem a little disinterested in this issue and even referred me to examples in their documentation where they say the padlock won't show, as if that was acceptable!