python：双向部分信用卡存储加密
对于我的电子商务网站，我想将部分信用卡号存储为字符串，为此，我需要对存储在数据库中的信息进行加密，并在用户想要重复使用之前购买时已输入的信用卡信息而无需全部输入时进行解密再次。
我正在使用 Django，因此我需要通过 Python 来解决这个问题。解决这个问题的聪明算法是什么？
For my ecommece site, I want to store partial credit card numbers as string, for this I need to encrypt the information to store at the database and decrypt when users want to reuse the already entered credit card info from earlier purchases without typing it all over again.
I am using Django thus I need to solve this via Python. What would be the clever algorithm to solve this issue ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在您进一步了解之前，您应该先看看 PCI-DSS，它准确地控制了您需要执行哪些流程甚至考虑存储加密的卡号。简而言之，您应该认真考虑外包给第三方支付网关。
如果您了解后果后确实想继续，请再次遵循 PCI 指南。对于卡号的对称加密，您可能需要使用 AES ，并制定非常严格的密钥管理政策< /a>.
然而，如果您只想存储部分卡号，那么 PCI 规定您只能存储（最多绝对最大值）前六位和后四位数字。前六位数字足以识别卡类型。您可能认为有必要使用最后四位数字，以帮助防止客户拥有几乎相同的卡号的问题。
恕我直言，您想要做的就是存储部分卡号（以纯文本形式），然后将加密、授权和结算的处理外包给 第三方网关。支付网关将为您传递给他们的每张卡提供一个唯一的令牌 ID，以便您可以引用唯一的卡来执行重新授权或退款等操作。
Before you go much further you should take a look at PCI-DSS, which governs exactly what processes you need to have in place to even consider storing encrypted card numbers. In short, you should seriously consider outsourcing to a 3rd party payment gateway.
If once you've understood the consequences you do want to go ahead, then again - follow the PCI guidelines. For symmetric encryption of card numbers you probably want to use AES, and draw up very strict key management policies.
If however you only want to store a partial card number, then PCI states you can store (at an absolute maximum) the first six and last four digits only. The first six digits are all you need to identify a card type. The last four digits you may deem necessary to help prevent issues where a customer has near identical card numbers.
IMHO storing partial card numbers (in plain text) is what you want to do, and then outsource the handling of encryption, authorisation and settlement to a 3rd party gateway. The payment gateway will give you a unique token id for each card you pass to them, so that you can reference a unique card to perform re-authorisation or refunds etc.
您绝对确定要像这样对敏感信息进行哈希处理吗？可能值得阅读这篇文章来了解一下尝试在数据库中存储任何敏感信息的一些陷阱。就您而言，情况更糟，因为您希望转换是可逆的。请记住，如果您可以逆转它，那么攻击者也可以。
在开始本课程之前请仔细考虑...
也许您最好将此类工作外包给专门从事该工作的人（例如 Paypal 或 Google Checkout 等）。
Are you absolutely sure you want to hash sensitive information like this? It might be worth reading this article to get an idea of some of the pitfalls trying to store any sensitive information in a database. In your case it's even worse because you want the transformation to be reversible. Just remember, if you can reverse it, so can an attacker.
Think carefully before you embark on this course...
Perhaps you might be better of outsourcing this kind of work to someone who specializes in it (such as Paypal or Google Checkout etc).