Secure hashing of PAN requires salt
December 28th, 2007 by admin Posted in Encryption
One of the topics that always comes up (as it has in the forum) is that of how to satisfy the “strong one-way hash functions” aspect of PCI DSS requirement 3.4.
We discussed the alternative to encryption, secure hashing, earlier this year, but it’s always good to remind everyone of it. If you receive any of the following, you are not receiving “cardholder data”:
- Securely hashed PAN
- Masked PAN (displayed or output to other media)
- Truncated PAN
The reason for this is that you cannot ever get from any of the above (i.e. truncated PAN) back to the original data — at least without significant guess work, at which point you are just generating numbers.
But what about rainbow tables some people ask? Well, if you read the Wiki article it clearly states, “[A] salt is often employed with hashed passwords to avoid this attack.”
It is important that you always salt your hash or else it is not considered “secure”.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
9 Responses to “Secure hashing of PAN requires salt”
By A Cryptographer on Dec 28, 2007
I’d suggest you read up on the topic a bit more before dishing out advice. The fact is that your pre-image space for a PAN is so small that a brute force attack is almost as viable as pre-computation (certainly for any SHA or MD algorithms). There’s no question that appending a salt would slow down an attack, but it’s far from secure.
By Michael Dahn on Dec 28, 2007
Can you please share more information such as actual numbers and/or resources?
I agree the pre-computation space is rather small but without knowing the salt value, one would have to pre-compute an almost infinite number of hashes.
By Branden R. Williams on Dec 29, 2007
Here’s the thing on Hashing. Theoretically, you could create a hash that is as secure as a CipherText from an encryption algorithm. If you used a 10 kilobit salt (effectively your key) plus your PAN, you would have something quite secure, and would not run into issues with collisions. The problem is that you cannot change your keys without retaining the original PAN. If you did, none of your hashes would line up. In addition, people treat hashes differently then they do CipherText. Hashes seem to become this “non-real value that cannot be reversed†when they can with rainbow tables. Conversely, you don’t see symmetric encrypted values thrown around an organization in the same manner. If you could solve the key change issue, plus keep them secure like you would CipherText, then we are almost comparing Apples to Apples.
By DAG on Dec 31, 2007
A Cryptographer raises an interesting point that cuts to the difference between compliance with the DSS standard and security. But at the same time the criticism is wrongly aimed.
While much of the DSS represents good practice, there are areas which are open to debate. Should any form of WEP be allowed? What protection before authorization is required? Etc. Etc.
The real challenge with PCI comes when you try and read between the lines. While a lot of the broad brush issues are out in the open, the public isn’t privy to the risk assumptions upon which the standard is based. When things change or when we illuminate some of the subtler aspects covered by the standard balancing security and compliance can get tricky.
Michael’s post hits on one of the subtler areas of the PCI DSS. You can almost hear eyeballs glazing over whenever anyone dives into the subtleties of 3.4. It’s unavoidable.
The DSS states hashing is sufficient without even a mention of salting. SHA-1 is given as the example, but I have seen nothing saying MD5 isn’t acceptable. Hashing and salting aren’t even in the glossary.
Now I personally don’t like hashing solutions for a number of reasons. Some are security related with the small PAN space being central to that. Others are operational. There are also minor and annoying implementation worries like possible collisions that you need to overcome. Salting helps the security side and hurts the operational side.
Hashing does allow you to avoid some of the thornier aspects of key management which is the real obstacle to using encryption.
But let’s step back for a moment. Think about masking/truncation. For a 16 digit PAN keeping the allowed 6 and 4 digits, our guess work is cut to 1 in 100,000 since only one in ten of the missing digits will pass the check digit calculation. Therefore the PCI DSS implicitly accepts the risk that guessing on 1 in 100,000 is okay.
The problem is that hashing, although non-reversible is still unique. If you can manage to get the processing power, you can overcome it.
Another problem with hashing is that the state of the art has lagged behind encryption. So when we choose hashing as a solution, we are necessarily less certain as to its strength than we should be with encryption. That should drive our solutions to be more conservative from a security design perspective. And by more conservative, I don’t mean sticking with MD5. But for many PCI has blessed hashing and that will be enough for them.
Now once you’ve hashed, or hashed and salted, you really still must be very careful with the data. And in particular you must be careful to ensure that you can’t combine notionally “harmless” data like hashes and truncated data for the same data set. That could easily amount to a computational “gimme”. That is the real security issue.
Ultimately, compliance with the PCI DSS will improve security. This discussion is just another example that compliance is not the same as security. Compliance will leave you residual risks and security issues. Discussions like this help people to understand that and consider those questions when they make their choices.
By Michael Dahn on Dec 31, 2007
@DAG, I like your comment. It’s interesting, because the reality behind compliance is that it does not necessitate perfect security, only the amount that will prevent fraud. Most security people think that prevention requires perfect security, but this is incorrect. Prevention only requires making obtaining the data more costly than the data is worth. With encryption it’s not about computation because anyone can “generate†credit card numbers using a credit card number generator. The question is, what can someone do with these numbers? It is not economical for someone to test authorize every possible card number with every possible expiration date.
In order to understand what is required to protect something, we need to first understand the methods that people use to obtain and then monetize that thing.
By Jeff Hall on Jan 1, 2008
At the end of the day, it all comes down to what I refer to as the ’six sigma’ rule of security. By that, I mean that security measures, properly implemented, prevent 99.9999% of the population from obtaining your information.
However, that final 0.0001% of the population is out to get your information regardless of whatever security measures you have put in place. And this small group of individuals will do whatever it takes to gain the information they desire from you or your organization.
So while we can discuss all day long the pros and cons of various security measures, the question to be asked is if the security measure in question is reasonable and will it protect the information appropriately based on the knowledge that no security measure is ever absolutely secure.
I only broached the subject on the Forum because I wanted to get the opinion of other QSAs regarding whether or not hashing was acceptable without additional controls.
By EK on Jan 3, 2008
Jeff, as I understand it, the DSS does not require salted hashes. This is based on many things, including clients that have gotten written clarification that salting is not required. I still encouraged them to salt the data.
From a security standpoint I completely agree with you. A secure hash needs to be salted. Especially with data as small as a PAN.
As a QSA it is my job to help my clients understand the DSS and be reasonably certain that they are compliant. As a security expert I want to help them understand the implications, especially when I think there is sufficient residual risk to warrant additional security. These two parts of my job don’t always fit together well and it is important to recognize the differences.