因此，就像任何合理的网站开发商店一样，我们在接触信用卡时戴上棉手套，我们使用Braintree SecureVault存储它们，以便我们清楚PCI合规性问题。
然而，现在我们想为我们的服务提供免费试用，这几乎取决于能否保证给定的信用卡仅用于免费试用一次。理想情况下，我们可以散列信用卡号码本身以保证唯一性。问题在于，有效的信用卡号码很小，因此很容易暴露信用卡号码。就我所见，腌制策略是无用的，因为如果有人可以访问哈希数据库，他们很可能也会有代码，因此也就是盐析算法。
目前最好的两个想法是：
A）将哈希值隔离在一组中，与其结算信息无关。因此，如果哈希是强制性的，他们所拥有的只是一个在某个时间点使用的信用卡号码列表，没有个人信息或知道它是否仍然有效。这里的主要缺点是我们确实记录了最后4个可能用于在某种程度上匹配它们的记录。
B）没有完整数字的哈希并处理误报和否定。哈希的名字，最后4和到期应该是相当独特的。误报就像赢得彩票一样，我们可以在客户支持下处理它。通过修改名称可以引起假阴性，我们不清楚我们对名称匹配的精确性有什么保证（可能受到网关和商家帐户的影响是我的理解），所以这可能会打开一个漏洞。
思考？建议？经过实战考验的智慧？
答案 0 :(得分：1)
高级别：使用现有付款系统
我认为这种方法 - 使用信用卡号码来确定用户是否已经利用免费试用并且不符合后续免费试用的资格 - 是错误的。首先，您将通过预先要求信用卡（许多用户不提供信用卡，除非他们实际上已准备好购买）来驱逐潜在客户，而不是仅在试用期结束后才要求信用卡。
其次，你正在重新发明轮子。有许多“应用商店”（Chrome网上商店，Android市场，iTunes应用商店等），它们提供支付和试用期的内置机制。使用这些系统将使您的产品对消费者的可见性增加，将为您的潜在客户提供多种不同的付款方式（使他们更倾向于购买），并且还可以节省您自己实施此机制的麻烦。此外，用户通常更愿意向尽可能少的公司提供信用卡;您不仅需要自己实现这种复杂的机制，而且还必须让用户信任您足够使用它。
下级：实施细则
任何哈希机制都可能发生冲突，因此您仍然需要处理此问题。显然，您应该对服务器使用完整磁盘加密和其他最佳安全实践。通过将后端数据库服务托管在与托管此代码的机器不同的机器上，可以降低同时损害数据库和盐析算法的风险。散列的主要漏洞是暴力攻击。处理它们的最好方法就是让暴力破坏足够昂贵以至于攻击者不值得。对每个条目使用单独的盐（例如客户的名称，客户的邮政编码等作为盐的一部分）将使彩虹表无效。当然，使数据本身对攻击者的价值较低（例如不包括完整的信用卡号）也是阻止这类攻击的好方法。在任何情况下，我再次建议您利用许多应用商店，而不是自己实现。
答案 1 :(得分：0)
原谅我，如果我错过了什么，但为什么你不能只有一个“UsedCreditCards”表只有一个列，这是一个信用卡号的SHA512哈希值，可能是到期日期。这是无法逆转的，并且通过将其保存在另一个表中而不存储有关代码的任何其他数据，您可以轻松检查以前是否使用过信用卡号。
我不确定这是否会违反PCI或其他任何事情（我不这么认为，但我可能错了）