Credit card tokenization overview

You will often hear of online and in store retailers in which credit card numbers are stolen. This is often due to storing the card numbers locally in an encrypted status. As soon as a hacker obtains the encrypted value, it is a matter of time before the value can be un-encrypted by a brute force attack.

Tokenization eliminates that particular risk. Rather than store them in a local database, the practical implementation normally involves using a third party such as First Data to store the Primary Account Number (“PAN”) and the token to which it is mapped.

The simplest example of this in the real world is a casino chip. Taking a bag of casino chips outside of the casino is worthless, as they have to be redeemed at the casino. The casino in this case is the token service such as First Data.

If this is the first transaction for the shopper, the application passes the card to First Data who returns a token. This is a period of vulnerability, as the vendor has the unencrypted card. However, this is the only point of vulnerability. Even this can be sent over a tunneled connection that is encrypted in transit.

This token is stored in the application database, as it is useless outside of a relationship with First Data for this application.

For future transactions, the application passes the token for the shopper to First Data, who looks it up in a highly secure mapping table and returns a status (not the original PAN) to the application. The token returned is normally in the same format as the original PAN, to ensure the application still works with regard to database column length, display format, etc.

A database mapping table may look like the following:

PAN			TOKEN
4434-5678-9876-5432	7342-9156-0852-4913

First Data in this case verifies the card number is good, then returns a true status to the application that it can proceed. There is no need in that case to store the credit card number locally, which removes the PCI audit requirements. This is a huge plus.

Below is a simple implementation in python. The datastore on the token server is not secure, and it is on the same host, but the concept holds. The “client” sends a token to the “server” which looks it up in its in memory list of tokens (again, only for a simple example), and returns a true or false status depending on whether the token was found.

import socket, sys

def getTokenStatus(token):
  port = 5000;
  remote_ip = socket.gethostbyname("localhost")
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.connect((remote_ip , port))
  s.sendall(token)
  reply = s.recv(4096) 
  print reply

def startTokenServer():
   
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.bind(("localhost", 5000))
  s.listen(10)
  while 1:
    conn, addr = s.accept()
    print 'Connected with ' + addr[0] + ':' + str(addr[1])
    data = conn.recv(1024)
    if not data: 
      break   
    conn.sendall(returnTokenStatus(data))
 
  conn.close()
  s.close()

def returnTokenStatus(token):
  #this list represents our stored tokens
  tokens = ["1234123412341234","2345234523452345","3456345634563456"]
  if token in tokens:
    return "True"
  else:
    return "False"

if sys.argv[1] == "client":
  getTokenStatus(sys.argv[2])  
elif sys.argv[1] == "server":
  startTokenServer()