1

我正在考虑如何在我的 Rails 应用程序上开发验证，该应用程序基本上检查以确保任何用户用于任何给定交易的信用卡在我们的系统中是唯一的，这样所有信用卡都可以用于购买物品在整个应用程序中为所有用户只使用一次，永远。

这个限制背后的想法是这个应用程序有时会运行时间敏感的促销交易，我们希望尽最大努力为这些交易建立“一张信用卡购买”系统。

我正在考虑对信用卡号进行哈希处理并将该哈希存储在数据库中，然后在每次新购买时交叉引用它（所以我的支付网关保留实际数字，我只是在数据库中保留一个哈希） ，但在进一步的研究中，这似乎是个坏主意。

所以我回到了绘图板并寻找新的想法。任何人都知道解决这个问题的好方法，同时尽可能保持 PCI 兼容？

我正在使用 Rails 3 进行开发，并使用 ActiveMerchant 与我的支付网关 Authorize.net 集成，如果这有帮助的话。

4

5 回答 5

1

当然，一些散列是一个坏主意——要么是因为它的安全性低，有一些拦截，要么是因为彩虹表很常用。这并不意味着所有散列都是一个坏主意 - 交叉引用的唯一方法将是某种唯一且可预测地识别信息的方法。除非 PCI 明确禁止它 - 散列仍然是要走的路。

盐

确保你给你的哈希加盐——这可以防止彩虹攻击，或者至少需要彩虹攻击者建立一个考虑到你的盐的表。特别是如果您可以使盐保持合理的安全{我之所以说是合理的，是因为要生成盐，您需要拥有盐，这意味着它将在某处的代码中}。

选择一个好的算法

虽然 MD5 现在臭名昭著，并以各种语言实现，但它也很常见，您可以找到预制的彩虹表。生成哈希也非常快。您的系统可能可以容忍少量延迟，并使用更多处理器密集型哈希。这使得生成彩虹表的成本更加昂贵。以Tiger 算法为例。

多次散列

如果您有多个相关数据点，则多个哈希将使进行彩虹攻击变得更加困难。例如： Hash(Hash(Card#+salt1)+expireDate+salt2) - 需要知道卡号和生成日期（对您来说很容易），但不容易逆向工程（每张卡都需要彩虹） # * 每个有用的过期日期 + 两种盐的知识）。

编辑：（您的评论）

相当安全：仅通过加密连接（SFTP、SSH）传输它，不要以未加密的方式存储它 - 包括实时/迭代和备份副本，将带有盐的文件保存在网络树之外（不能直接访问/意外释放)，确保对文件的权限尽可能严格（不允许组/全局文件访问）。

将随机值扔进散列的动态盐对于减少彩虹攻击非常有用——你将随机部分与散列值一起存储在表中——现在在构建彩虹时，你必须为每个动态盐构建一个彩虹。但是，根据您的需要，您不能这样做 - 您需要知道第二次创建哈希时要使用的正确随机盐（否则您将永远不会在第二次使用卡时得到拦截）......为此可预测/可重复然后您必须将动态盐基于数字的某些部分......这实际上是与另一个数据点的多重散列所做的。您拥有的数据点越多，您可以在这个方向上散列越多 - 例如，如果您有 CVV（3 个散列），或者您一次散列 8 个数字（总共 3 个散列：）hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)。

Best Hash它是一个移动的目标，但在 security.stackexchange 上有一个很好的讨论。这指向 SHA-512。

于 2012-02-03T21:44:42.523 回答
1

在线伪造您的真实信用卡号码是防止这种情况发生的最佳方法。花旗银行客户可以登录并使用所有账户提供的此工具。只需生成一个数字和到期日期以供在线使用，现在一切都很好。

于 2012-02-04T14:53:35.860 回答
0

如果您想要“每个用户一次购买”系统，那么为什么不在用户尝试购买特价商品时检查他们的购买历史以确保他们以前没有购买过呢？

于 2012-02-03T21:32:21.507 回答
0

我认为你正在寻找错误的方向。我只会检查最后 4 个卡、IP 和送货地址。如果少数用户玩弄最后一个 4 & ip 解决方案，则存储该数据的风险与损害是不值得的。（他说不知道购买的性质。）

由于没有收集地址...前 4、后 4 和 4 位到期（当然都是散列）应该提供您需要的唯一性，以确保该卡只使用一次。

于 2012-02-03T22:02:19.647 回答
0

用户可以注册多个帐户。

虽然通过检查用户历史记录，以及为每次购买强制每个地址购买 1 件商品——你可能会没事——你也可以通过用户名/生日/任何其他识别信息来限制事情。

顺便说一句，信用卡信息也可以更改-实际上很容易购买 100 张带有唯一编号的礼品信用卡，因此，如果您想将事情控制到最细微的程度……我认为您仅通过 cc 就无法做到数字

于 2012-02-03T21:40:52.980 回答