防止使用同一张信用卡多次购买？
我正在考虑如何在我的 Rails 应用程序上开发验证，该验证本质上是检查以确保任何用户用于任何给定交易的信用卡在我们的系统中都是唯一的，以便所有信用卡都可以用于购买商品所有用户在整个应用程序中始终仅一次。
此限制背后的想法是，该应用程序有时会运行时间敏感的促销优惠，我们希望尽力为这些优惠建立“每张信用卡一次购买”系统。
我正在考虑对信用卡号进行哈希处理，然后将该哈希值存储在数据库中，然后在每次新购买时交叉引用它（因此我的支付网关保留实际号码，而我只在数据库中保留哈希值） ，但是进一步研究，这似乎是一个坏主意。
所以我回到绘图板并寻找新的想法。有人知道解决这个问题的好方法，同时尽可能保持 PCI 合规吗？
我正在使用 Rails 3 进行开发，并使用 ActiveMerchant 与我的支付网关 Authorize.net 集成（如果这有帮助的话）。
I'm thinking through how to develop a validation on my Rails app that essentially checks to make sure that the credit card used for any given transaction by any user is unique in our system, such that all credit card may be used to purchase an item only once across the entire application for all users, for all time.
The thinking behind this restriction is that this app will sometimes run time-sensitive promotional deals, and we want to do our best to institute a "one purchase per credit card" system for these deals.
I was thinking of hashing the credit card number and just storing that hash in the db, then cross-referencing it at the time of each new purchase (so my payment gateway keeps the actual number, and I just keep a hash in the DB), but on further research, this seems like a bad idea.
So I'm back to the drawing board and looking for new ideas. Anyone know a good approach to this problem, while keeping as PCI-compliant as I can be?
I'm developing with Rails 3 and using ActiveMerchant to integrate with my payment gateway, Authorize.net, if that helps at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当然，一些散列是一个坏主意 - 要么因为它的安全性低，有一些拦截，要么因为彩虹表很常用。这并不意味着所有散列都是一个坏主意 - 交叉引用的唯一方法将是某种唯一且可预测地识别信息的方法。除非 PCI 特别禁止，否则散列仍然是可行的方法。
加盐
确保为哈希加盐 - 这可以防止彩虹攻击，或者至少要求彩虹攻击者在构建一张表时考虑到你的盐。特别是如果你可以合理地保证盐的安全{我之所以说合理是因为为了生成你需要有盐，这意味着它会在代码中的某个地方}。
选择一个好的算法
虽然 MD5 现在臭名昭著，并且以各种语言实现，但它也很常见，您可以找到预制的彩虹表。生成哈希值也非常快。您的系统可能可以容忍少量延迟，并使用处理器密集程度更高的哈希值。这使得生成彩虹表的成本更加昂贵。例如，查看 Tiger 算法。
多次哈希
如果您有多个相关数据点，多次哈希将使彩虹攻击变得更加困难。例如： Hash(Hash(Card#+salt1)+expireDate+salt2) - 需要了解卡号和生成日期（对您来说很容易），但不容易进行逆向工程（rainbow 需要每张卡） # * 每个有用的过期日期+两种盐的知识）。
编辑：（您的评论）
相当安全：仅通过加密连接（SFTP、SSH）传输，不要以未加密的方式存储它 - 包括实时/迭代和备份副本，将带盐的文件保留在网络树之外（无法直接访问/意外释放），确保文件的权限尽可能受到限制（不允许组/全局文件访问）。
动态盐将随机值放入哈希中对于减少彩虹攻击非常有用 - 您可以将该随机片段与哈希值一起存储在表中 - 现在，在构建彩虹时，您必须为每个动态盐构建一个彩虹。然而，根据您的需要，您不能这样做 - 您需要知道第二次创建哈希时使用的正确随机盐（否则您将永远不会在第二次使用卡时获得拦截）...为此可预测/可重复，然后您必须将动态盐基于数字的某些部分......这实际上是与另一个数据点进行多重哈希的作用。您拥有的数据点越多，您可以朝这个方向散列的数据就越多 - 例如，如果您有 CVV（3 个散列），或者您可能一次散列 8 个数字（总共 3 个散列：
hash(hash （哈希（1..8+salt1）+9..16+salt2）+expDate+salt3））。最佳哈希这是一个不断变化的目标，但有一个很好的讨论security.stackexchange。它指向 SHA-512。
Certainly some hashing is a bad idea - either because it's low security, has some intercepts, or so commonly used there's rainbow tables. That doesn't mean all hashing is a bad idea - the only way to cross reference is going to be some way of uniquely and predictably identifying the information. Unless PCI specifically prohibits it - hashing is still the way to go.
Salt
Make sure you salt your hash - this prevents rainbow attacks, or at least requires the rainbow-attacker build a table with your salt in mind. In particular if you can keep the salt reasonably secure {I say only reasonably because in order to generate you need to have the salt which means it'll be in code somewhere}.
Choose a Good Algorithm
While MD5 is now infamous, and implemented in all kinds of languages, it's also so common that you can find pre-made rainbow tables. It's also extremely quick to generate a hash. Your system can probably tolerate a small amount of delay, and use a much more processor-intensive hash. This makes the cost of generating a rainbow table much more expensive. Check out the Tiger algorithm for example.
Hash more than once
If you have multiple related data points, multiple hashes are going to make it way harder to do a rainbow attack. For example: Hash(Hash(Card#+salt1)+expireDate+salt2) - requires knowledge of both the card # and the date to generate (easy for you) but can't easily be reverse-engineered (rainbow requires for every card # * every useful expire date + knowledge of both salts).
Edit: (your comments)
Reasonably secure: Only transmit it over an encrypted connection (SFTP, SSH), don't store it unencrypted - including live/iterative and backup copies, keep the file with the salt outside of the web tree (cannot be directly accessed/accidentally released), make sure permissions on the file are as restrictive as possible (don't allow group/global file access).
Dynamic salt throwing a random value into the hash is great for reducing rainbow attacks - you store that random piece in the table with the hashed value - now when building a rainbow you have to build one for every dynamic salt. However for your needs you can't do this - you need to know the right random salt to use the second time you create the hash (otherwise you'll never get an intercept on the second card use)... for that to be predictable/repeatable you'd then have to base the dynamic salt on some part of the number... which is effectively what multiple hashing with another data point does. The more data points you have the more you can hash in this direction - if you have the CVV for example (3 hashes), or perhaps you hash 8 digits at a time (for a total of 3 hashes:
hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)).Best Hash it's a moving target, but there's a good discussion on security.stackexchange. Which points to SHA-512.
伪造您的真实在线信用卡号码是防止这种情况发生的最佳方法正在发生。花旗银行客户可以登录并使用所有账户提供的此工具。只需生成一个号码和到期日期以供在线使用，目前一切都很好。
faking your true credit card number online is the best way to prevent this from happening. Citibank clients can login and make use of this tool provided with all accounts. Just generate a number and exp date for use online, and all is fine , for now.
我认为你找错了方向。我只检查卡、IP 和送货地址的最后 4 个。如果少数用户玩了最后 4 场游戏，则存储该数据的风险与损坏的风险之间的关系可能会受到影响。 ip解决方案不值得。 （他说不知道购买的性质。）
由于没有收集地址...前 4 位、后 4 位和 4 位数字到期时间（当然都是散列的）应该提供您所需的唯一性，以确保该卡仅使用一次。
I think you are looking in the wrong direction. I would just check last 4 of card, ip and shipping addresses. The risks of storing that data versus the damage if a small number of users gamed the last 4 & ip solution is not worth it. (He says not knowing the nature of the purchases.)
Since address isn't collected...First 4, Last 4 and 4 Digit Expiration (all hashed of course) should provide the uniqueness you need to ensure that card was only used once.
如果您想要一个“每个用户一次购买”的系统，那么为什么不在用户尝试购买特购商品时检查他们的购买历史记录，以确保他们以前没有购买过呢？
If you want a "one purchase per user" system then why don't you just check the user's purchase history whenever they try to buy a special-purchase item to ensure that they haven't bought it previously?
用户可以注册多个帐户。
尽管通过检查用户历史记录，以及每次购买每个地址强制购买 1 件商品，您可能会没事，但您也可以通过用户姓名/生日/任何其他识别信息来限制内容。
顺便说一句，信用卡信息也可能会发生变化 - 实际上很容易购买 100 张具有唯一编号的礼品信用卡，因此如果您想将事情控制到最细微的级别...我认为您无法仅通过抄送数字
user could register for multiple accounts.
although by checking users history, as well as enforcing 1 item per address for each purchase- you will likely be fine- you could also limit things by users name/ birthday/ whatever other identifying information.
Credit Card information can also change by the way- its actually very easy to purchase 100 gift credit cards with unique numbers so if you want to police things down to the most minute level... I dont think you will be able to just by cc numbers