我正在考虑如何在我的Rails应用程序上开发验证，该应用程序基本上检查以确保任何用户在任何给定交易中使用的信用卡在我们的系统中是唯一的，这样所有信用卡都可以用于
在所有用户的整个应用程序中仅为一次购买一件商品。这一限制背后的想法是，这个应用程序有时会运行时间敏感的促销优惠，我们希望尽最大努力为这些交易制定“每个信用卡购买一次”系统。
我正在考虑对信用卡号进行哈希处理，然后将该哈希值存储在数据库中，然后在每次新购买时交叉引用它（因此我的支付网关会保留实际数量，而我只是保留哈希值数据库），但on further research, this seems like a bad idea。
所以我回到绘图板并寻找新的想法。任何人都知道这个问题的一个很好的方法，同时保持与我一样的PCI兼容性？
我正在开发Rails 3并使用ActiveMerchant与我的支付网关Authorize.net集成，如果这有帮助的话。
答案 0 :(得分：1)
当然，一些哈希是一个坏主意 - 或者因为它的安全性低，有一些拦截，或者常见的是彩虹表。这并不意味着所有散列都是一个坏主意 - 交叉引用的唯一方法是以某种方式唯一且可预测地识别信息。除非PCI明确禁止它 - 哈希仍然是要走的路。
盐
确保你的哈希值 - 这可以防止彩虹攻击，或者至少要求彩虹攻击者在你的盐中建立一个表。特别是如果你能保持盐的合理安全{我说的只是合理的，因为为了生成你需要有盐，这意味着它将在某处的代码中}。
选择一个好的算法
虽然MD5现在臭名昭着，并且以各种语言实现，但您也可以找到预先制作的彩虹表。生成哈希也非常快。您的系统可能会容忍少量延迟，并使用更多的处理器密集型哈希。这使得生成彩虹表的成本更加昂贵。例如，查看Tiger algorithm。
哈希不止一次
如果您有多个相关数据点，则多个哈希值会使得进行彩虹攻击变得更加困难。例如：哈希（哈希（卡＃+ salt1）+ expireDate + salt2） - 需要知道卡＃和生成日期（对你来说很容易），但不能轻易地进行逆向工程（每张卡都需要彩虹） ＃*每个有用的过期日期+两种盐的知识。）
编辑（您的评论）
合理安全：仅通过加密连接（SFTP，SSH）传输，不要以未加密的方式存储 - 包括实时/迭代和备份副本，保留文件外的盐Web树（无法直接访问/意外发布），请确保文件的权限尽可能严格（不允许组/全局文件访问）。
动态盐向哈希值中添加一个随机值非常适合减少彩虹攻击 - 您可以使用散列值将该随机块存储在表中 - 现在在构建彩虹时，您必须为其构建一个彩虹每一个动态盐。然而，根据您的需要，您不能这样做 - 您需要知道第二次创建哈希时使用正确的随机盐（否则您将永远不会在第二张卡使用时获得拦截）...因为它是可预测/可重复的，你必须将动态盐基于数字的某些部分...这实际上是与另一个数据点进行多次散列的情况。您拥有的数据点越多，您可以在此方向上进行散列越多 - 例如，如果您有CVV（3个哈希值），或者您可能一次哈希8个数字（总共3个哈希值：hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)）
Best Hash 它是一个移动目标，但有一个很好的discussion on security.stackexchange。哪个指向SHA-512。
答案 1 :(得分：1)
答案 2 :(得分：0)
如果您想要“每个用户购买一次”系统，那么为什么不在用户尝试购买特殊商品时检查用户的购买历史记录，以确保他们之前没有购买过该产品？
答案 3 :(得分：0)
用户可以注册多个帐户。
虽然通过检查用户的历史记录，以及每次购买每个地址强制执行1个项目 - 您可能会很好 - 您还可以按用户名称/生日/其他任何识别信息限制事项。
信用卡信息也可以改变 - 它实际上非常容易购买100张具有唯一号码的礼品信用卡，所以如果你想把事情调到最微小的水平......我不认为你将能够只是通过cc号
答案 4 :(得分：0)
我认为你看错了方向。我会查看最后4张卡，IP和送货地址。如果少数用户在最后4＆amp; ip解决方案不值得。 （他说不知道购买的性质。）
由于未收集地址...前4，后4和4数字到期（当然所有哈希值）应提供确保该卡仅使用一次所需的唯一性。