hash - Is there a secure way to guarantee credit card uniqueness? -

so, reasonably competent web development shop, wear cotton gloves when touch credit cards, , use braintree securevault store them clear of pci compliance issues.

however want offer free trial our service, pretty relies on being able guarantee given credit card used once free trial. ideally able hash credit card number guarantee uniqueness. problem there set of valid credit card numbers small, it's going easy brute force credit card numbers. salting tactics useless far can see, because if has access database of hashes, have code well, , salting algorithm.

the best 2 ideas far are:

a) keeping hashes isolated in set, no relation billing information. therefore if hashes brute-forced, have list of credit card numbers used @ point in time, no personal information or knowledge of whether it's still valid. main weakness here have record of last-4 potentially used match them extent.

b) hash without full number , deal false positives , negatives. hashing on name, last-4 , expiration ought unique. false positive winning lottery, can deal @ customer support. false negative induced modifying name, not clear on assurances have precision of name matching (potentially affected both gateway , merchant account understanding), open loophole.

thoughts? suggestions? battle-tested wisdom?

high-level: use existing payment systems
think approach -- using credit card numbers determine if user has taken advantage of free trial , should ineligible subsequent free trial -- misguided. firstly, drive away potential customers requiring credit card upfront (which many users don't give out unless ready buy), instead of requiring after trial period has ended.

secondly, reinventing wheel. there plethora of "app stores" (the chrome webstore, android marketplace, itunes app store, etc.) provide builtin mechanisms payment , trial periods. using these systems give product increased visiblity consumers, offer potential customers multiple different payment methods (making them more inclined buy), , save hassle of implementing mechanism yourself. plus, users prefer give out credit card least number of companies possible; not have implement complex mechanism yourself, have users trust enough use it.

lower-level: implementation details
hash mechanism can have collisions, hence still need deal problem. should use full disk encryption , other best security practices servers. risk of having both database , salting algorithm compromised @ same time can reduced hosting backend database service on separate machine 1 hosts code. main vulnerability of hashing brute force attacks. , best way deal them make brute forcing expensive enough isn't worth attacker's while. using separate salt each entry (e.g. customer's name, customer's zip code, etc. part of salt) make using rainbow tables ineffective. of course making data, itself, less valuable attackers (e.g. not including full credit card number) way discourage these kinds of attacks. in case, again advise take advantage of many app stores instead of implementing yourself.