Truncate (or hash) and forget about it
March 26th, 2007 Posted in Compliance, PCI DSS
In the Yahoo! PCI User Group, Todd asked a question that I am going to change so it sounds little broader:
I have a client that has chosen to no longer store PANs. If they were to truncate, etc. the existing data, would they no longer need to comply with [PCI DSS]?
An interesting thing about PCI is that it applies only to companies that “store, process, or transmit” cardholder data. (Ok, it also includes systems connected to those that fall within scope, but let’s forget this for a moment.)
If a company accepts cardholder data (i.e. PAN) only to hash or truncate it before it is stored, they may want to examine why they are accepting the full PAN in the first place. If a company or computer accepts the PAN and then truncates it, they must be compliant. But, if they accept a truncated PAN they can remove that computer (or in rare cases, the entire company) out of scope.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
6 Responses to “Truncate (or hash) and forget about it”
By BP on Dec 18, 2007
I need clarification..
Reading PCI DSS, if a system stores a PAN, then it’s in PCI scope. PCI DSS also mandates that all stored PANs should be unreadable, e.g. encrypted, hashed, or truncated.
So my interpretation is that stored PANs (for this case either encrypted or hashed) is still witin PCI scope. If this wasn’t true, then only full clear-text storage of PANs would be in scope, and that doesn’t make sense.
So back to my point — encrypted (or hashed) storage of pans is still within PCI scope.
BUT — some posts suggest if you only store hashed PANs (or hash+salt), the storage system is longer in scope. That does not seem right — it doesn’t seem to convey the intent of PCI. Thoughts?
By Michael Dahn on Dec 19, 2007
The idea is that if you receive the PAN and then hash it, you are in-scope because you had access to the original data.
If you only receive a hashed (w/ salt) or truncated PAN then you are not technically receiving cardholder data because there is no way for you to get back (reverse) to the actual PAN.
By BP on Dec 19, 2007
Thank you — after circling around the concept a few times, it now makes sense. My organization has a reasonably disperse e-comm system, so correctly minimizing the number of in-scope systems is a critical first step in our PCI compliance project. The clarification you provided is appreciated.
By Michael Dahn on Dec 28, 2007
Please note the hash must be ’salted’ for it to be considered “secure”.
By BP on Dec 28, 2007
1. When you say the hash must be salted, do you mean a unique salt per PAN that is stored along side the hashed PAN, or a single salt used for all PANs and hidden (although the meaning of “hidden”, and how secure that is, can be a whole discussion).
2. From what I’ve gathered: A salted hashed PAN is deemed ok for storage outside of PCI scope. A truncated PAN is apparently ok too (e.g. only store first 6 and last 4). But what about storing the hash as well as the first 6, last 4? While the PCI DSS doesn’t comment on this, using combinations of truncation/hasing/encryption/etc could substantially weaken security. E.g. knowing first 6/last 4 significantly reduces the magnitude of a dictionary attach against the hash.