So, like any reasonably competent web development store, we wear cotton gloves when we touch credit cards and we use Braintree SecureVault to store them, so we do not meet the PCI Compliance requirements.
However, now we want to offer a free trial version of our service, which relies heavily on the ability to ensure that this credit card is used only once for a free trial. Ideally, we could hash a credit card number to guarantee uniqueness. The problem is that the set of valid credit card numbers is small, so it will be easy to overdo the credit card numbers. As far as I understand, salting tactics are useless, because if someone has access to the hash database, they will most likely have code and, therefore, salting algorithm.
The best two ideas so far:
A) Storage of hashes allocated in the set, without regard to their payment information. Therefore, if hashes are grossly forced, all they have is a list of credit card numbers that were used at a particular point in time, without personal information or knowing whether it is still valid. The main weakness here is that we have a record of the last 4, which could potentially be used to match them to some extent.
B) A hash without a full number and deal with false positives and negatives. Hashing by name, last-4, and expiration should be quite unique. A false positive is a victory in the lottery, we can deal with it with the support of customers. A false negative can be caused by a name change, we don’t know what assurances we have about the accuracy of matching names (potentially affected by both the gateway and the seller’s account - this is my understanding), so this can open a loophole.
Thoughts? Suggestions? Fighting wisdom?
source
share