20 July 2018
Andrew Churchill

Technology Strategy

Andrew Churchill - Technology Strategy

3Posts 9,991Views 19Comments

Mere tokenism - how not to deploy security

09 February 2015  |  3066 views  |  0


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, (http://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.

TagsSecurityMobile & online

Comments: (0)

Comment on this story (membership required)

Latest posts from Andrew

Mere tokenism - how not to deploy security

09 February 2015  |  3066 views  |  0 comments | recomends Recommends 0 TagsSecurityMobile & online

For once, it's not Government taking your money!

27 August 2012  |  2801 views  |  1 comments | recomends Recommends 0 TagsSecurity

The computer you are reading this on is mine ...

24 July 2012  |  4125 views  |  0 comments | recomends Recommends 0

Andrew's profile

job title Director
location London
member since 2009
Summary profile See full profile »
Research into security flaws of Government and payment industry systems, particularly in relation to Identity and authentication, and development of security solutions to address attacks against such...

Andrew's expertise

Member since 2009
3 posts19 comments
What Andrew reads
Andrew writes about
SecurityMobile & online
Andrew's blog archive
2015 (1)2012 (2)

Who's commenting on Andrew's posts