5

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?

Improve this question
2
  • 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
    Commented Sep 7, 2013 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
    Commented Sep 7, 2013 at 22:26

3 Answers 3

Reset to default
2

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.

Improve this answer
2
  • 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
    Commented Sep 5, 2013 at 21:25
  • 1
    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 ♦
    Commented Sep 5, 2013 at 22:05
4

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.

Improve this answer
1
  • 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
    Commented Sep 5, 2013 at 22:35
0

The PCI DSS glossary defines the minimum of 112-bits of effective key strength (see Strong Cryptography) and this is referenced in the main standard (e.g. req 2.2.3).

Wikipedia shows the effective strength of the various hashing algorithms under the SHA-1 entry. This shows MD5 as having <64 bits, and SHA-1 <80 bits. SHA-2 and -3 series are presently looking much better and are supported out of the box for the mainstream tools / development environments.

PCI DSS also references OWASP, and their "Cryptographic Storage Cheat Sheet" states "Do not use weak algorithms, such as MD5 or SHA1.".

It'd be great if we could get one list of all of these various ciphers and algorithms and get a definitive statement of their relative strength to avoid arguments with auditors / banks / lawyers.

Improve this answer
1
  • 1
    This is misleading. "key strength" is a property of ciphers (like AES) and does not apply to hash functions like MD5. These two kinds of algorithms face completely different attack modes and required strength for one does not apply to the other.
    – billc.cn
    Commented Sep 13, 2016 at 17:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .