I understand that using MD5 is not safe and is not PCI compliant.

Does using BCrypt satisfy PCI compliance

  • 2
    Usually if you have need to store a credit card number, you want to be able to decrypt it later, so you can use it again for payment. What reason do you have to store only a hash of the number, which is a one-way function and cannot be decrypted? Oct 10, 2013 at 20:44
  • bcrypt is not an encryption algorithm, but a hashing algorithm. You should first start by understanding the difference, unless you meant hashing in the first place (perhaps English is not your mother language, like me).
    – Ion
    Oct 11, 2013 at 10:57
  • @martinstoeckli , to use the same credit card for payment, I use the processor's tokenization.. I tokenize the card and perform auth with that token. I need the hash of the card because saving the card in plain text is out of the question, and to identify that this card has been added to the database (for historical reporting, what transactions were performed by which card for a certain client).
    – Wael Awada
    Oct 13, 2013 at 5:00

2 Answers 2


I understand that using MD5 is not safe and is not PCI compliant.

Sadly enough, it rather can be in some cases: https://security.stackexchange.com/a/41868/836

Does using BCrypt satisfy PCI compliance

The substantive problem is that the credit card number space is so short that brute forcing is basically always reasonable. I think that the question pattern you should be asking is:

  • "Am I allowed to store this data?"
  • "What is the most secure solution to what I'm trying to do?"
  • "Is the solution I came up with compliant?"

Thus, what we should be talking about is why you need to store this data and how you'll access it, confirming that PCI says you can store it, then figuring out the appropriate response.

... here's the direct answer:

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

  • One-way hashes based on strong cryptography (hash must be of the entire PAN)

... which BCrypt would satisfy. Further reading: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

  • well when we perform a transaction for a customer C1 with creditcard CC1, we store that information. When C1 comes for another order, if he uses C1, we do not want to insert a new credit card for him. We are trying to avoid the first 6 last 4 (even though that is pci compliant).
    – Wael Awada
    Oct 10, 2013 at 19:11
  • 1
    > credit card number space is so short that brute forcing is basically always reasonable --- When hashing it alone, true, but you can avoid that by using a good quality salt (random and long) Oct 11, 2013 at 9:47
  • 1
    @jpkrohling - You should think of the salt as a known value, it is not a secret. It will not make it harder to brute-force a single value, but can prevent an attacker to build a rainbow-table to get all numbers at once. Oct 11, 2013 at 12:42
  • 1
    @martinstoeckli True, for some reason I had the password case in mind and instinctively thought that it applies also for credit card numbers. Oct 11, 2013 at 13:14

Are these two questions or one? Brypt is not using MD5 and is one of the strongest password derivation functions. However, as any one way function, it should be seeded with a secret (salt), especially if the input is of low randomness, such as payment card numbers.

You must log in to answer this question.

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