I get asked this a lot, but default MD5 and SHA-1 hashing algorithms should not be acceptable means to render cardnumbers unreadable in the eyes of a security professional, or QSA.
Although the hashing algorithm itself is secure, any information that has been hashed using MD5 or SHA-1 is now easily retrievable through the use of rainbow tables.
Rainbow tables contain hash values for any common permutation of text. For example, www.cmd5.org has the MD5 hash values of over 750,000,000,000 alphanumeric text values and numbers. Other rainbow tables have the values of all hash values for credit card numbers (let's say range from 4000,0000,0000,0000 through to 4999,9999,9999,9999. So it's as simple as comparing an MD5, SHA-1 or SHA-2 hash to the values in this database to reveal the true card number.
So what can you do about it?
Well, the problem with commonly available hashing algorithms is that they all use a default method (I suppose you could equate this to a common encryption key), so in affect, the criminal underworld already knows your decryption key.
One way round this is to change the defaults (this also comes under PCI DSS v2.1, change vendor defaults) and add an additional value (known as a nonce, or salt) to the algorithm. As this value is hopefully unknown to the criminal fraternity (unless your sysadmins work for them), then they can't use standard rainbow tables to defeat your hash. This can be a small 8 bit value. A rainbow table corresponding to your 8 bit value is very unlikely to exist, although I'm sure in 5-10 years time, computing power will be sufficient for rainbow tables within rainbow tables to be generated with ease.
Alternatively, SHA-256/512 might buy you some time, as the available rainbow tables take some considerable grunt to generate and certainly there aren't any around containing all credit card numbers yet (10,000,000,000 numbers). Well. I can't find any, but I'm sure the US Government have a few sets kicking around seeming the NSA devised SHA in the first place.
In conclusion, it is a wise step not to hash sensitive data, as sooner or later, technology will exist that can reverse this. If you are going to hash data, why not encrypt it first? You'll still have your unique values to perform comparative checks with and worse case scenario, hackers get ciphertext to play with.
I do hope other QSAs follow suit here as have come across quite recent ROCs and SAQs that quite happily tick MD5 and SHA-1 off as ‘in compliance'. Mind you, even the PCI SSC's guidelines do not explictly forbid MD5/SHA-1 and maybe they should take NIST's advice with a pinch of salt (federal agencies should not use MD5 and should phase out SHA-1 by 2010…).