使用 mcrypt 或 GnuPG 存储信用卡详细信息答案

【问题标题】：Storing credit card details with mcrypt or GnuPG使用 mcrypt 或 GnuPG 存储信用卡详细信息
【发布时间】：2012-10-12 09:30:06
【问题描述】：

我需要存储信用卡详细信息（不存储不是一种选择）。

使用 mcrypt 和 mcrypt_dev_random 生成 init_vector 需要不同的时间来加密/解密，但似乎是最“安全”的选项。 mcrypt_dev_urandom 快得多，但不适合长期存储 - 正如我所读到的那样。

将 GnuPG 视为一种可能的替代方案，如果可能的话，希望得到一些意见/建议。

【问题讨论】：

安全地存储信用卡是一项非常重要的任务，如果您在 Stack Overflow 上询问如何去做，那么您几乎没有希望以正确或合法的方式去做。跨度>
@meagar 我对一切都很满意，但在流程中引入更多工作的选项会牺牲速度。
哇。你在做什么产品？我想像瘟疫一样避免它。 “只要不耽误事情”是您在处理存储信用卡号码时可能采取的最糟糕的态度。如果您做错了，您是否了解您个人（而不是您的客户）的大量法律后果？您是否明白这不是您可以在以后插入并充实细节的东西？你绝对不想自己这样做。你会弄错了，结果对所有相关人员来说都是灾难性的。
您需要做的就是放弃自己实现此功能的任何希望，并联系知道他们在做什么的专业人士3rd party。即使这样，他们也会审核您的系统，以确保它足够安全以与他们的系统交互。这不是玩笑，这简直就像互联网上的安全问题一样严重。
@meagar 我确实知道后果，我当然不记得说过我想为速度牺牲任何东西——整个前提是衡量解决方案——而不是在我们的系统上这样做是一种选择。再往下，我确实提到我们将使用多个提供程序 - 因此问题是 - 如果我们只使用一个提供程序并且没有切换，那么这将不是问题。

标签： php encryption mcrypt

【解决方案1】：

对您而言，最重要的问题是，您需要什么才能实现 PCI 合规性。不要产生一些自制加密。阅读它需要什么，最好将信用卡的东西委托给专门的支付处理器。

使用 mcrypt 和 mcrypt_dev_random 生成 init_vector 需要不同的时间来加密/解密，但似乎是最“安全”的选项。 mcrypt_dev_urandom 快得多，但不适合长期存储 - 正如我所读到的那样。

这说明了一些误解。一方面，静脉注射不需要保密。随机数的质量不太重要。

但即使对于密钥，/dev/urandom 也足够好，只要它最初具有足够的熵。

【讨论】：

【解决方案2】：

如果您真的想要安全地存储信用卡信息，有一个标准：Payment Card Industry Data Security Standard。而且它比使用一种特定的加密算法更多涉及更多。 ~~它要求您将部分卡详细信息存储在两台物理上独立的机器上，~~ 等等。即使您严格遵守 PCI 标准，专家仍认为您仍然没有完全安全。任何低于此的内容都几乎不值得详细讨论，因为整体安全级别非常低，几乎没有什么区别。

【讨论】：

OK - 后退一步或三步 - 将使用一些“不太安全”的东西，例如解锁随机数生成器和基于某些指标的几种算法之一，然后将生成的加密数据拆分到物理系统中有利...基本上有没有一种情况是为了速度而使用较少随机的向量创建方法是可以接受的？
@Ian Speed 应该是您最不关心的问题。加密/解密永远不会超过几分之一秒，也许一秒。目标是使其安全，对吗？好吧，即使您确定了加密过程，要使其真正安全，您需要做的是锁定正在运行的系统。如果没有人可以进入您的系统，即使是未加密的存储也足够安全。但是弱点是有人可以访问解密该数字所需的所有部分。那么加密它的具体方式就无关紧要了。 PCI 涵盖了所有这些...
@deceze 实际上，为初始化向量生成随机性的方法可能需要大量时间 - 在 *nix 上使用 mcrypt_dev_random 等待熵池填充 - 测试显示加密时间超过 200 秒！
对此的最终想法（希望如此）... - 我已经加密了数据。将 IV 与密文一起存储，将 base64 编码的密码分片并存储在多台物理机器上；分片可以应对 1 个节点丢失并仍然重建。我已经请求了一些专家咨询 - 当这种情况发生时谁知道，但希望这能进一步满足合规性要求。
@deceze "将部分卡详细信息存储在两台物理上独立的机器上"

【解决方案3】：

记住：密码学的第一条规则是“不要自己动手”。

MCRYPT_DEV_URANDOM 足以进行强大的加密，但是“管理信用卡信息”比简单地“加密所有信息”要复杂得多让上帝来整理自己的”。

“不存储不是一种选择”对我来说听起来好像你（或者更好，你上面的人）做错了。您不应该研究这个，或者是提出解决方案的人。不要成为堕落的家伙。

https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php

【讨论】：

谢天谢地，我没有打电话，因此不要接受包装！但我确实听到了。该要求基本上是由于使用了不同的支付提供商，因此我们需要能够在不让用户重新输入详细信息的情况下进行切换。我并不是说这是一个正当的理由——只是已经规定的......
在这种情况下，我将部分收回“不要自己做”，并建议用该用户的密钥加密每个用户的CC数据（他应该如果他重置帐户密码，则必须重新输入这些详细信息）。