I have two locations within the same firm that hold credit card numbers. I want to be able to "join" on credit card number to do business analytics after transmitting card number-linked data from one location to another.

The credit card number itself isn't actually needed to link the datasets. A token, with zero or very rare collisions, would be good enough.

The problem then becomes how to generate tokens in the two locations such that the same credit card maps to the same token, and do so securely.

Naively, one could just use a cryptographic hash, but since the space being mapped is so small (facially 10^16, but of course actually less than that), that's not a good solution, especially if the hashes aren't salted. (And it's not clear how salting would work and yet enable records to be linked anyway.)

One could also propose using strong symmetric encryption of the CCN's themselves, with very careful sharing of the secret key, but I'm not well enough versed in cryptography to know if the fact the set of plaintexts is so limited opens up the scheme to attack.

(NB: I know one shouldn't "roll your own crypto". I'm not directly on this project, but I'm curious about the solutions I hear being discussed.)

  • Don't use crypto for PCI elements like card numbers. Store the card numbers in a third location (a vault) which is hardened as much as possible and exposed only via a service to obtain a token not related to or derived from the original account number. Then you can put your security effort into the vault. – lonstar Jul 6 '15 at 17:39
  • Sorry if my question isn't clear. The business use case is that there are already two vaults, and for reasons beyond our control they cannot be merged. Of course, if there was a single vault, then as you point out one could generate an opaque token to serve the needs I'm asking for. – user1071847 Jul 6 '15 at 18:07

The first thing I would do is run any proposed solution past your PCI auditor to ensure your not going to deploy anything which will cause issues and put the company outside of PCI compliance.

It sounds like all you need is to have the card numbers tokenized in such a way that you will always get the same token given the same card number and there is no requirement to go back the other way? This would indicate you are after a hash rather than encryption. You can add a salt as well.

A lot would depend on what data will be associated with this information. If the only data you have linked to those hashes (outside your very secure vault) is the hash of the card number and no other personally identifiable data, such as card holder name etc, then a good hash, with a salt to increase the length, will likely be sufficient. Credit card numbers just by themselves without other information are not that useful. We already know the algorithm to verify valid credit card numbers and so could just as easily generate large numbers of valid card numbers. It is only when you can add the additional information, such as expiry date, card holder name etc that the data becomes really useful.

On the other hand, if your going to include additional sensitive data in your work, then I would be looking at ways to generate a unique token which does not rely on the credit card number - customer id or possibly a hash which consists of multiple fields - it really depends on the details of what your trying to do.

In general, think of the worst case scenario - don't assume your solution is safe. Instead, assume someone will be able to reverse engineer it at some point. then do a risk assessment of what the impact will be if they are able to do it. Then look at ways you can reduce that impact as well as ways to reduce the likelihood. For example, be very sure that all the data is actually needed - sometimes, just removing some bits of data can make all the difference. Also consider what controls you can put into place to alert you to a problem i.e. detection of unauthorised access, response to unauthrised access, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.