28 June 2017
Mark Sitkowski


Mark Sitkowski - Design Simulation Systems Ltd

3Posts 9,569Views 21Comments
A post relating to this item from Finextra:

US supermarket chain Supervalu confirms network hit by 'criminal intrusion'

15 August 2014  |  7593 views  |  0
US supermarket chain Supervalu has become the latest retailer to admit that it has been hacked and that customer card data may have been stolen.

The Flaw in POS terminal security. Solved

18 August 2014  |  3854 views  |  3

However advanced the security model used by a retailer's point of sale terminals, whether it be biometrics, EMV cards, one time passwords or any other kind, the single point of failure is the fact that useful data is left behind on the retailer's system.

This makes it an attractive target for hackers, who bypass the authentication system, by hacking the network, or the operating system, steal the database, and re-use the card details, user information and whatever else was there for the taking.

To perform identity authentication, only two pieces of information are needed. A form of user ID, and an associated secret, known only to the user and the authentication system.

In most cases, the user ID is implied by a credit card number, and the secret is passed from the user, to the retailer, and then to the credit card company, possibly in encrypted form. All of this information is recorded, together with the transaction details, in the log files on systems belonging to the retailer and the credit card company.

This is the flaw. The systems contain data worth stealing. It doesn't matter that it is encrypted, since the thieves have plenty of time, and adequate computing resources.

Let us postulate a point of sale terminal which doesn't need to read a credit card number, but is content to take a simple user ID.

Let us further postulate that the terminal doesn't pass a secret to the credit card company, but merely sends metadata, i.e information related to the secret. Now, we don't even need encryption.

Finally, let us postulate that the metadata is different with each transaction performed by the customer, but relates to the same secret.

Both the customer and the credit card company know the secret, so deciphering the metadata is a simple matter. The retailer doesn't need to know the secret, and just retransmits the metadata from customer to credit card company. If the whole transaction is stored on the retailer's system, and is then stolen, it is useless to the thief, since he can't decipher the metadata.

The creation of the metadata is the crucial part of this security model, and the following is one approach.

Both the customer and the credit card company agree on a word or phrase, or even an arbitrary collection of letters, as the secret.

When the customer wishes to authenticate, the POS terminal presents him with an alphabet, paired with a random array of numbers, like this:



The customer then enters the numbers corresponding to his secret, which are sent to the credit card company. It doesn't matter if the retailer stores this together with the transaction details since, the next time the customer performs a transaction, the numbers will all be different, and the previous numbers will be useless to the thief.

The numbers will also be useless to any spy camers, skimming devices, network snoopers and key logging malware.

To add a further level of security, it isn't even necessary to transmit the numbers. A SHA256 hash is irreversible, but the credit card company can reconstruct the hash of the secret, and match this with the incoming hash from the retailer.

Point of sale terminals can be made secure. Very secure. It's just a matter of wanting to.

TagsRetail bankingTransaction banking

Comments: (6)

A Finextra member
A Finextra member | 19 August, 2014, 09:54

Are you, perhaps, familiar with PIN's and PIN Blocks?  Welcome to planet Earth...

You need to Verify the Token (Card) and Authenticate the User (Customer) - Card Verification is handled in a number of ways (sure you know them all) - Customers are Authenticated using their PIN - which in the future may be replaced or complimented with (passively or actively obtained) Biometric information to further secure a transaction.

Incidently - something similar to your proposal already exists: 3DSecure - and it is about as secure as my sisters piggy bank...

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Mark Sitkowski
Mark Sitkowski - Design Simulation Systems Ltd - Melbourne | 19 August, 2014, 10:44

@A Finextra Member: Are you, perhaps, familiar with spy cameras, network snoopers, key logging malware, or stolen retail databases?  Welcome to the Internet...

Looks to me as if you didn't understand any of the above - especially if you compare it with 3DSecure.

Coupled with a card number (even on a smart card), a PIN gives an attacker access to whatever account relates to the card - and don't even bother to mention biometrics. Biometric data is transmitted digitised, so even my grandmother could write a trivial TCP/IP script to intercept it, store it, and use it in another TCP/IP script to access a bank account, or whatever. After what happened at Target, any system which leaves usable data behind, is hackable.

Using the above system, if a retailer loses the database, the thief will gain several thousand user ID's, and several thousand strings, like '100001110001'. All attempts to use these, will fail, since the next authentication challenge will contain a totally different set of random digits.

Just to make things more interesting, there is also the possibility of embedding a variable length prefix and suffix of random digits, so the attacker doesn't even know how long the original keyword was.

Perhaps we should write a version to use on piggy banks.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
A Finextra member
A Finextra member | 19 August, 2014, 12:56

Spy Cameras?  You mean you don't cover your hand whilst entering your PIN?

If a Retailer is PCI:DSS compliant there is not enough data in their databases to be useful.

P2PE should resolve any network concerns - although most (if not all) retailer connections are via private leased connections.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Mark Sitkowski
Mark Sitkowski - Design Simulation Systems Ltd - Melbourne | 19 August, 2014, 22:55

@A Finextra Member: I must confess, along with 90% of the population, I think 'It can't happen to me'. Not that that would have helped Target, since the 'spy camera' was inside the POS terminal, reading the RAM which drives the display.

Also, they were very PCI/DSS compliant, which didn't prevent their own FTP server from being hijacked, and the data from being transmitted (encrypted, of course) across their VPN, and out to the C&C in Mother Russia. The first people arrested, were using cloned EMV cards, together with their decrypted PIN's, to buy stuff in Mexico.

As I said, there is no defence if you store actual data. The only solution is to give the parasites nothing they can use.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
A Finextra member
A Finextra member | 20 August, 2014, 11:50

Cloning EMV cards with data from a purportedly PCI:DSS compliant Merchant?  Could you explain how that works in practice - as this would surely mean the Merchant logging (and accessing) prohibited data from the MagStripe and Chip? 

Where is the evidence to prove this occurred?

Now what "might" have happened is the track 2 may have been compromised and cloned - however - again - that would mean logging of prohibited data (i.e. not PCI:DSS compliant).

There is a whole lot more to "cloning an EMV card" than capturing Merchant data - IMK's for example.


Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Mark Sitkowski
Mark Sitkowski - Design Simulation Systems Ltd - Melbourne | 21 August, 2014, 01:51

@A Finextra Member: That's not really in my scope. If you want to know how it all happened, check back numbers of Finextra or the New York Times. If you want to knowhow to stop it happening again, check www.designsim.com.au.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)

Latest posts from

Mark's profile

job title Consultant
location Melbourne
member since 2012
Summary profile See full profile »
Consultant at SteelPlatez Security, managing fraudproof ATM and online banking project. Skills include Unix, TCP/IP, Agile, PMBOK, Oracle, javascript and anything technical

Mark's expertise

Member since 2012
2 posts21 comments
What Mark reads
Mark's blog archive
May 2017 (1)2015 (1)2014 (1)

Who's commenting on Mark's posts