hash - 有没有一种安全的方式来保证信用卡的唯一性？

Question

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

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

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

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

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

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

Answer 1

高级别的:使用现有的支付系统
我认为这种方法——使用信用卡号码来确定用户是否已经利用了免费试用并且应该没有资格获得随后的免费试用——是错误的。首先，您将通过预先要求信用卡(许多用户除非他们真正准备好购买否则不会提供信用卡)来赶走潜在客户，而不是仅在试用期结束后才要求信用卡。

其次，你正在重新发明轮子。有大量的“应用商店”(Chrome 网上商店、Android 市场、iTunes 应用商店等)提供内置的付款和试用期机制。使用这些系统将提高您的产品对消费者的可见度，为您的潜在客户提供多种不同的支付方式(使他们更倾向于购买)，并且还可以省去您自己实现这种机制的麻烦。此外，用户通常更愿意将信用卡发放给尽可能少的公司；您不仅必须自己实现这种复杂的机制，而且还必须让用户足够信任您以使用它。

底层:实现细节
任何哈希机制都可能有冲突，因此您仍然需要处理这个问题。您显然应该对服务器使用全盘加密和其他最佳安全实践。通过将后端数据库服务托管在与托管此代码的计算机不同的计算机上，可以降低数据库和加盐算法同时受到损害的风险。哈希的主要漏洞是蛮力攻击。处理它们的最好方法就是让暴力破解变得足够昂贵，以至于不值得攻击者花时间。为每个条目使用单独的盐(例如，客户的姓名、客户的邮政编码等作为盐的一部分)将使使用彩虹表无效。当然，使数据本身对攻击者的值(value)降低(例如，不包括完整的信用卡号)也是阻止此类攻击的好方法。无论如何，我再次建议您利用许多应用商店，而不是自己实现。