1

Suppose that the data in question is a card PAN. According to PCI-DSS, you have to store it with extra security (encrypt it before storing in database and store the secret key elsewhere with more restricted access).

But what if you had to support searching based on PAN?

A. The straight forward solution would be receive a plain PAN, send it to the backend which goes through all the PANs in database, decrypts them, sees if they match the input, and then return the record with the needed data based on what is attached to that PAN (which sounds bad performance-wise).

B. Would hashing be a solution? When a new PAN is created, encrypted and stored encrypted, a hash for the PAN can also be calculated (not reversible but still hiding the real sensitive PAN). - should it have a salt? - can the salt be stored same place as the hash? or does it have to be store in a more secure place, like a secret key? - is the salt shared with the searcher? should the searcher do the hash and pass the hash around ? or should it just pass the plain PAN around and let the hashing be re-done close to where the original hashed PAN (PAN digest) is?

C. Is the entire concept of supporting search by encrypted data bad from start (and it should not even be supported because there is no good solution for it without compromising on the extra security)?

D. Is there any other secure way to do indexing of sensitive data?

Info Sec
  • 11
  • 2
  • Worth noting: if the user will be keying in the number to search for, your web server will have clear text card data traversing it, which may be yet another problem. – Bobson Oct 29 '18 at 23:06
  • Why would you want to search? What is your actual use case? – Jack Oct 30 '18 at 06:39
  • @Jack don't know the use case, yet. it is in some other application. i just know there is a search with PAN. – Info Sec Oct 30 '18 at 09:30
  • @Bobson Clear text PAN in communication is not an issue if the communication is encrypted (tls being used) – Info Sec Oct 30 '18 at 09:31
  • @InfoSec It’s not the communication part that’s the problem. Since the server will have cleartext card data, it requires all the extra restrictions and protections that go with that. It also means SAQ-D instead of a lesser one. These may not be issues at all, but I just want to call them out. – Bobson Oct 30 '18 at 11:27

1 Answers1

1

PCI requires the data be unreadable. This is generally done through encryption or hashing. As you state above, decrypting for the purpose of searching is a terrible idea for performance. Hence, hashing is a great option for fast searching and a strong hash is recommended/required. The PCI DSS doesn't require a salt be used. If you want to use a salt, it should be static to support the search speed requirement. If storing both truncated PAN and hashed PAN, you should be using a salt.

AndyMac
  • 3,149
  • 12
  • 21