Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just had a vendor tell me that because their PCI auditors did not recommend banning the use of unsalted MD5 to store sensitive data at this time with with their current level of PCI compliance that they're not going to ban the use of MD5 to store sensitive data.

NOTE: The vendor declined to say if the auditors: (1) discovered the vendor was using MD5 to store sensitive data, but said it was not an issue; (2) did not discover they were doing it, but said using MD5 to store sensitive data was okay; (3) did not discover they were doing it, and not say using MD5 to store sensitive data was okay; (4) if their level of PCI compliance does not require MD5 hashes to not be used to store sensitive data per the PCI Security Standards Council. (5) etc.

Again, all they would say is their PCI auditors did not recommend banning the use of unsalted MD5 to store sensitive data.

Putting aside if banning the use of MD5 to store sensitive data is right or not, what levels of PCI compliance if any ban the use of unsalted-MD5 and/or MD5 to store sensitive data?

share|improve this question
It entirely depends what the ‘sensitive data’ are and what the reason is that hashes are being made. If the data are card numbers and the reason for hashing is that someone thinks this constitutes either tokenisation (to stop the data being considered sensitive) or what PCI calls “strong encryption”, they are very much mistaken. But the question is too vague as-is. – bobince Sep 7 '13 at 17:25
@bobince: Reality is vague sometimes, but provides the chance for amazing answers too. Agree that what's defined as sensitive might change the meaning of what is strong, but at the same rate, there is rarely the case that non-sensitive data needs strong encryption. Further, really doubt that at a high-level that buckets of sensitive data might not be define, and as a result, a means of knowing if the encryption was strong enough. Any thoughts? Please feel free to post an answer, since it appears you understand the topic better than I, and I'm always open to selecting a better answer. Cheers! – blunders Sep 7 '13 at 22:26
up vote 2 down vote accepted

PCI-DSS doesn't mention any algorithms. It only says that when using hashes, they should be one-way hashes based on strong cryptography. Depending on who you talk to, that might still include MD5 (ah well).

PCI-DSS is really a contract between the vendor and the credit card company. You probably want to have them provide you with a SOC 2 report with the stipulation that hashing algorithms are covered.

share|improve this answer
Thanks! Just to be clear: (1) Are they required to provide the SOC 2 report to customers if asked, or you're suggesting this would likely be the location of the related specs and the vendor would only have to provide it as a courtesy if they felt so inclined. (2) Is there any test for "strong", because if this is strong that in my opinion makes PCI-DSS sound like a joke. – blunders Sep 5 '13 at 21:25
PCI-DSS audits are not reports and aren't meant for anybody other than credit card companies. "Strong" is defined by them and pulling auditor status from lousy auditors. There are a great many who do think PCI-DSS is a joke, but that's another story. SSAE16/SOC[1-3]/the former SAS 70 type reports are never regulated, but customers of service organizations often require them from the service provider in order to do business (sometimes because regulations require that the customer have such a report to use the service, e.g. SOX). – Jeff Ferland Sep 5 '13 at 22:05

Using any hash algorithm to "fuzz" the card is often reversible.

Since there are only a finite quantity of card numbers, remember the last digit maybe a check digit. Not all the entire card space needs to be checked. It is well known what the card issuer prefixes are so you perform your searches there. So now your 16 digit PAN, lost the last digit for check digit and the first 4 to 6 for card issuer. That is not a lot of combinations to brute force, maybe a single PC with a GPU can do it in a few hours.

So even salted data is useless when you can exhaustively search the entire keyspace with a few clicks and an AWS or evil botnet cluster and get the results back in an hour. Computers are fast enough to cycle through ALL combinations to find the hash that matches. The salt is usually known and designed to protect against pre-computation, but that doesn't matter if you can re-compute a complete new data set based on known salt quickly.

So what is important is the exact algorithm used in conjunction with a hash like MD5.

What is the point of using MD5 anyway ? If you need a token the represent a card number issue it from an independent keyspace. A sequential counter starting at 000000001 and encrypted with a completely secret key will always grant you a unique output value for the blocksize that is completely unrelated to the card data (and therefore not reversible) without the mapping database being compromised.

If you really need to fuzz the card number look towards PBKDF2 for all usage where you considered a hash. Since you can bring back the intention of the salt by making it too costly to brute force (even on GPU even on AWS cluster).

Ask your PCI compliance people if you substituted number 0 for A, 1 for B, ... 9 for J, etc... and stored it in the database if this is "strong" enough.

Straight use of MD5 to fuzz card number (even with known salt) can be broken at the rate of 450million/sec on a GPU (from my quick google). Remember we lost some PAN digits to brute, so we can do 10 digit in 2 seconds.

Sorry if not 100% on topic but use of MD5 to "strongly" secure credit card is a joke in 2013.

share|improve this answer
Welcome to Security.SE, and while I agree your answer is, as you say, is a bit off-topic, thank you for sharing your take too! – blunders Sep 5 '13 at 22:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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