Mere tokenism - how not to deploy security

There has been much commentary of late over the surge in interest in tokenisation, not least on the back of certain mobile payment platforms. Tokenisation, as a principle, has of course been around for many years, but with the ever increasing prevalence of data breach disclosure notifications the adoption of ‘the token’ seems to coming of age.

The underlying value of the token is that it implements one of the basic principles of data security through minimising the amount of data disclosed to that which is essential to the transaction in hand. Therefore, as the token is a one-off, the subsequent disclosure of the token after its use does not present a concern. But as with many security techniques that have been so long in gestation, tokens solve one element of the problem without understanding that the problem has long since expanded, and indeed in many manifestations of tokenisation the adoption can actually open up new avenues of attack.

For the former, what a token does not do is ensure that it is being used for its intended purpose. Nor, in the latter, does it ensure that the token’s generation is at the behest of the intended user.  

Weak implementation of tokenisation has already started to hit the headlines, such as with the reports on anything up to 600 basis point fraud for one issuer with NFC through Apple Pay (http://www.droplabs.co/?p=1204). Given the paucity of US data on NFC transactions please forgive my recourse to last week’s UK NFC fraud figures, (https://www.finextra.com/news/fullstory.aspx?newsitemid=26978), but at 0.7 basis points these would support the hypothesised introduction of a critical vulnerability in the manner of Apple’s deployment, rather than its proclaimed additional layers of security.

This is not to take anything away from the concept of tokenisation, as it remains the case that static information should be kept at an absolute minimum. In the case of payments this absolute minimum means that the issuing bank alone must hold the static card data, as clearly it has to be able to identify the user. But even where issues of enrolment can be managed, the reliance on an easily circumvented local security metric to access a token generator provides little comfort for those organisations relying on this third party to handle the tokenisation of their static data.

It minimises the risk of the merchant system’s being compromised, but introduces a new single point of failure. As other security researchers have observed, and again please forgive me for mixing my fraud type metaphors, if an intermediary becomes an attractive repository of data, then they will become the focus of the attack. So if one must introduce a single point of failure then logically it should be the strongest link!

There will doubtless be many other flavours of ‘Pay’ available in the coming months, with a number expected at Mobile World Congress in Barcelona next month, but until the token is properly deployed they are likely to be as ephemeral as the tokens themselves.