3

因此,就像任何有能力的 Web 开发商店一样,当我们接触信用卡时,我们会戴上棉手套,并使用 Braintree SecureVault 来存储它们,这样我们就不会遇到 PCI 合规性问题。

然而,现在我们想为我们的服务提供免费试用,这在很大程度上依赖于能够保证给定的信用卡仅用于免费试用一次。理想情况下,我们能够对信用卡号本身进行哈希处理以保证唯一性。问题在于有效信用卡号码的集合很小,因此很容易暴力破解信用卡号码。据我所知,加盐策略是无用的,因为如果有人可以访问哈希数据库,他们很可能也有代码,因此也有加盐算法。

迄今为止最好的两个想法是:

A) 将哈希值隔离在一组中,与其计费信息无关。因此,如果哈希是暴力破解的,那么它们所拥有的只是一个在某个时间点使用过的信用卡号码列表,没有个人信息,也不知道它是否仍然有效。这里的主要弱点是我们确实有 last-4 的记录,这可能会在某种程度上用于匹配它们。

B) 没有全数的散列,处理误报和误报。名称、last-4 和过期时间的散列应该是相当独特的。误报就像中了彩票,我们可以在客户支持处处理。修改名称可能会导致漏报,我们不清楚我们对名称匹配的准确性有什么保证(我的理解可能受到网关和商家帐户的影响),因此这可能会打开一个漏洞。

想法?建议?久经考验的智慧?

4

2 回答 2

1

High-level: Use Existing Payment Systems
I think that this approach -- using credit card numbers to determine if a user already has taken advantage of a free trial and should be ineligible for a subsequent free trial -- is misguided. Firstly, you will drive away potential customers by requiring a credit card upfront (which many users don't give out unless they are actually ready to buy), instead of requiring it only after the trial period has ended.

Secondly, you are reinventing the wheel. There are a plethora of "app stores" (the Chrome webstore, the Android marketplace, the iTunes app store, etc.) which provide builtin mechanisms for payment and trial periods. Using these systems will give your product increased visiblity to consumers, will offer your potential customers multiple different payment methods (making them more inclined to buy), and will also save you the hassle of implementing this mechanism yourself. Plus, users generally prefer to give out their credit card to the least number of companies possible; not only would you have to implement this complex mechanism yourself, but you would also have to get users to trust you enough to use it.

Lower-level: Implementation Details
Any hash mechanism can have collisions, hence you would still need to deal with this problem. You should obviously use full disk encryption and other best security practices with your servers. The risk of having both the database and the salting algorithm compromised at the same time can be reduced by hosting the backend database service on a separate machine from the one that hosts this code. The main vulnerability of hashing is brute force attacks. And the best way to deal with them is to just make brute forcing expensive enough that it isn't worth the attacker's while. Using a separate salt for each entry (e.g. the customer's name, the customer's zip code, etc. as part of the salt) will make using rainbow tables ineffective. Of course making the data, itself, less valuable to attackers (e.g. not including the full credit card number) is also a good way to discourage these kinds of attacks. In any case, I again advise you to take advantage of the many app stores instead of implementing this yourself.

于 2011-02-10T00:59:32.390 回答
0

如果我遗漏了什么,请原谅我,但是为什么你不能只拥有一个只有一列的“UsedCreditCards”表,它是信用卡号的 SHA512 哈希值,可能还有到期日期。这无法逆转,通过将其保存在另一个表中并且不存储有关代码的任何其他数据,您可以轻松检查以前是否使用过信用卡号。

我不确定这是否会违反 PCI 或其他任何规定(我不这么认为,但我可能是错的)

于 2011-02-10T00:37:57.573 回答