Hashed PANs are a double edged sword.  Hashes seem to be coming up quite a bit lately, and in fact there was a question about hashed PANs at the PCI Europe meeting.

Luther Martin at Voltage discusses one of the two main issues with hashing, and that is the ability to create rainbow tables whereby you can easily take a known hash value and back your way to the input used to create it.  Granted, one of the issues that exacerbates this for cardholder data is the limited keyspace in which card numbers are valid.  Remember they all start with published six digit BINs, and any number must pass a Luhn check.  But, before we dance on hashing’s grave, let’s explore this a bit.

Corned beef hash pasty, by joyosity

Corned beef hash pasty, by joyosity

Hashing can be much more effective in protecting cardholder data when a “salt” is used.  Salts are akin to a password or encryption key for hashing, but implemented in a different manner.  Let’s say that you have a card number, 4111111111111111, and you want to create a hash of this value.  A straight MD5 hash would yield the value ‘fe745cd9e5facbc7951a700008a69bc1’.  Now, if I added the phrase StayClassySanDiego to the beginning of that value, I get a completely different output of ‘1997aba33a8b1f0336df73be6c8d7e61’.

Building rainbow tables are still possible if you know the salt, but without that knowledge you will not be able to (in a feasible time frame) build your rainbow table, thus making the hash a bit more secure.

I mentioned that this is one of the TWO issues with hashing, so what’s the other one?

When you look at hashing vs. encryption, the main difference is the ability to mathematically go from ciphertext to plaintext with the appropriate key.  Encryption enables you to do this while hashing does not.  So if you are hashing and then destroying your initial input (i.e., in this case, the PAN), you have no way to change your hashing method if some part of it is disclosed, like the salt.  If you humor me for a moment and consider the salt for a hash and the key for encryption to be equals, then realize that because you are destroying your plaintext, you can NEVER change your keys when you hash!

This is one major benefit to encryption in that you can change the locks if you suspect that the key has been stolen (and are required to by PCI DSS requirement 3.6.5).  So even if you look at Voltage’s own Format Preserving Encryption where you can force the output into predetermined formats, or set only certain parts of the PAN to encrypt, you still have the advantage of reversible encryption and the ability to change the locks if you need to.  No such luck with hashing.

Hashing is not dead, but it needs to be used in the appropriate manner.  Knowing that a PAN is valid is certainly one big step to earning the ability to use the payment instrument in the system, but you need more information.  Most online retailers require at least an address verification check before approving the purchase.  So a hashed value by itself with some basic transactional data, such as the amount purchased, is much less valuable than a hashed value in the same table as the cardholder’s personal information.

The Technical Working Group had a great stance on the overall concept of encryption, hashing, and truncation, in that the goal is to devalue the data.  Realize that you will likely take different measures for devaluing the data depending on where in your infrastructure it lives and what it is used for, but the point is to be sure you are taking the most appropriate action with card data everywhere in the process to devalue the data while still being able to use it for your business.

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts: