The thefts of credit card details from a host of retail outlets and, more recently, from a series of hotel chains, underlines the fundamental weakness in the way point of sale terminals handle authentication data. In fact, anywhere a credit or debit card is used, such as an ATM or online store, suffers from the same vulnerability.

Although credit card authentication falls within the strict definition of ‘Two Factor’, the reality is, that it should be treated as only one factor. In terms of security, it is no better than username/password, since the user inputs both factors -  the card number, and the PIN.

Biometric authentication essentially condenses the username and password into one (digitised) fingerprint, leaving the card number as a bonus for the hacker.

Most hack mechanisms will lift all of this data so, just for the sake of completeness, here’s a short list:

1.    Hidden camera – records the keystrokes of your user ID, PIN or password

2.    Over-the-shoulder observer – memorises your keystrokes.

3.    Keystroke logger – records your user ID, PIN or password

4.    Magnetic stripe skimmer – records your card number, which is your user ID

5.    Network snooper – records your user ID, PIN, card number and anything else.

6.    Screen scraper – reads everything present in the frame buffer, as Target discovered to its cost.

In the case of Target, the malware performed all of the above functions, with the exception of the hidden camera and observer, and that kind of breach continues to collect victims to this very day.

Let’s make the assumption that, thanks to The Enemy Within, or thanks to carelessness on the part of the company, there is every chance that a hacker will gain access to the network of an organisation.

Given that, the only viable defence is to ensure that any stolen information is totally useless.

This means that we must assume that anything typed can be read, and that all in-flight data can be collected, can be decrypted and any hash can be brute-forced to reveal what was sent.

When considering countermeasures, let’s initially postulate a challenge-response protocol, instead of card-swipe and PIN, and let’s replace the entropy-lacking four-digit PIN with an alphanumeric password, preferably of more than five characters. We won’t use an ASCII-based challenge, since anything which reads the frame buffer will be able to see it. The same goes for the response, so we need to eliminate the keyboard.

One way of doing this, is to display the challenge as a bitmap, where the user clicks or taps the characters of the response, Then, the in-flight data would only consist of positional information, but this approach would be vulnerable to a replay attack, where the data is logged, and re-used to perform a subsequent login.

Randomising the characters of the challenge would prevent such an attack but, in the real world, POS terminals have no touch screen, and their resolution and screen size would make accessing individual characters extremely inconvenient for the majority of the population.

We’ll do this, instead:

We will go through the character set of our proposed challenge, and toss a coin to determine into which of two bitmaps to place it.

Instead of selecting an individual character, the user merely has to indicate which of the two bitmaps contains the character.

The character set can be upper case, lower case, both or full alphanumeric, as shown here, depending on the screen resolution, and required degree of entropy.

<Insert image of POS terminal>

Note that the screen resolution is now less important, since the user only has to press, one key (for example, the ‘7’ key) to indicate the upper bitmap, and another (for example the ‘9’ key), to indicate the lower.

Even if the hacker knows the significance of the ‘7’ and ‘9’, this is of no use to him, since a subsequent login by the same user will be presented with a different randomisation of the characters across the two bitmaps

The only piece of information the hacker has, is the length of the password, so let’s address that. Our system will permit a prefix and/or suffix (each of predetermined length), of random characters to be entered at the terminal. This represents very little effort on the part of the user, and hides the true length of the password.

Now, let’s look at the situation from the hacker’s perspective.

His malware can still read the frame buffer of the POS terminal, run the contents through an OCR, and figure out which bitmap contains which character. Admittedly, it has to be a more  fancy OCR, than the one used at Target, since it has to cater for 64 alphanumeric characters, and not just the digits 0-9, but it can be done.

.So, assuming the hacker wants to put in the extra hard work, what has he actually got away with? He has a challenge solution embedded in garbage of unknown length. He has 32 possible candidates for each letter in the solution, which has expired as soon as he recorded it.

The in-flight data is no help, as it just confirms what he already knows – or doesn’t and, if he has an accomplice, looking over your shoulder he, too, will memorise the solution to a challenge which will never be repeated.