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? – martinstoeckli Oct 10 '13 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 '13 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 '13 at 5:00

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 '13 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) – jpkrohling Oct 11 '13 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. – martinstoeckli Oct 11 '13 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. – jpkrohling Oct 11 '13 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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