存储信用卡信息答案

【问题标题】：storing credit card info存储信用卡信息
【发布时间】：2010-12-18 07:13:11
【问题描述】：

所以我想修改一个 PHP / MySQL 应用程序，以便安全地存储信用卡而不是 cvv 和银行帐户信息。 PCI DSS 需要 1024 RSA/DSA。少数用户将获得私钥，以解密帐户信息的批处理文件，以每月提交给支付处理器。我不清楚是否有可能拥有一个允许使用普通 8 位密码登录的用户安全地修改自己的帐户信息的系统。这似乎是不可能的，并且加密应该是单向的（即每个用户-> 管理员；永远不允许用户再次解密他们自己的信息），即使通过 SSL 连接，帐户信息也永远不会暴露给用户。还是有一种我不知道符合 PCI DSS 的适当且简单的方法来执行此操作？

【问题讨论】：

标签： encryption rsa pci-dss

【解决方案1】：

PCI DSS 不需要 1024 位 RSA 进行加密。旧版本的规范按名称提到了 AES 和 3DES，但我相信新版本只是指定了强加密。大多数人都在使用 AES 256。

使用非对称算法加密静态数据实际上并不奏效。对称算法效果最好。这允许应用程序在需要时访问卡数据。这并不意味着您必须再次向用户显示数据，它只是意味着当您需要获取数据时数据就在那里。如果您要存储信用卡授权信息，通常需要卡号进行结算。（这实际上取决于您的处理器具有的功能。一些小型企业级处理器为您存储卡，但这对于像 Paymentech 和 FDMS 这样的大型处理器是不可行的。）

问题是您必须定期轮换加密密钥。这通常是把每个人都搞砸的原因。如果您使用自己的加密，则需要确保您可以指定 n 个可访问的密钥，只要有使用这些密钥加密的数据即可。在任何时间点，只能使用其中一个密钥进行加密。除非您对 PCI 方面的加密和密钥管理有深入的了解，否则您可能希望使用商业产品。是的，这些很昂贵，但您必须通过构建或购买决策过程来确定最佳课程。

Ingrian（现为 SafeNet）为网络 HSM 提供了不错的产品。它将为您管理密钥并执行加密操作。也可以使用他们的数据库级加密集成，这样您根本不必更改您的应用程序。（尽管我认为 DB 级加密的安全性值得怀疑。）

这是一个非常深奥的主题；我在 PCI 上做了很多工作，并建议您聘请某人来指导您正确地进行操作。您将在错误启动和重做工作上花费大量资金，因此请尽早让审计员参与进来，至少评估您的需求并告诉您如何正确实施安全措施。

【讨论】：

来自 PCI DSS 词汇表：强密码学：...密钥的有效大小应满足可比较强度建议的最小密钥大小...。满足以下最低可比较密钥位安全性：* 80 位用于基于密钥的系统（例如 TDES）* 1024 位模数用于基于分解的公钥算法（例如 RSA）* 1024 位用于离散对数（例如 Diffie-Hellman），最少 160 位大型子组的大小（例如 DSA）* 160 位，用于椭圆曲线加密（例如 ECDSA）
您能解释一下为什么非对称密钥不能真正用于数据存储吗？我看到的优势是我可以要求授权用户将私钥存储在服务器以外的某个地方，然后在他们想要导出批处理文件以提交给支付处理器时通过 https 提供它。密钥将在内存中使用，而不需要在服务器文件系统上。虽然我不记得存储私钥是个问题，但我只是认为这是一个需要避免的弱点。（如有必要，可以设置 Apache，这样私钥就不会被记录。）
是的，我注意到了密钥轮换问题，但您让重要性更加清晰。因此，它们应该是一些季度作业，运行以使用旧（私有）密钥读取值并使用新（公共）密钥将它们写入数据库。
对于轮换 - 可能会查看 RSA RKM，看看您是否可以找到有关他们方法的信息。它基于策略自动执行，密钥集中存储、本地缓存，客户端库在本地进行加密。它很昂贵，但它为您提供了一个相当高性能的加密 + 密钥管理解决方案。我相信另一家名为 Protegrity 的公司也有类似的解决方案，但实施方式略有不同。关键管理领域如果做得不正确，是最让你头疼的地方。
非对称算法（又名公钥算法）需要两个密钥来加密和解密。众所周知，用户在防止重要信息丢失方面很糟糕，因此除非您存储私钥，否则您最终可能会导致其中一些人无法访问他们的数据。如果您同时存储公钥和私钥，则本质上是将它们用作对称密钥（也称为基于密钥的系统）。非对称加密比对称加密慢。这真的取决于你在做什么。如果您只是存储他们的数据，那么非对称可能会起作用，因为它与问题域匹配。

【解决方案2】：

如果您区分数据存储、访问和传输，您可能会更轻松。

存储需要强可逆加密；除非您可以检索数据，否则数据没有用处。

访问要求用户或进程在被允许解密数据之前对其自身进行身份验证。以下是实现此目的的机制示例：

使用永远不会直接向任何用户公开的密钥存储数据。当然，您需要将那个密钥存储在某个地方，并且您必须能够检索它。
当每个用户选择密码时，使用密码为该用户加密私钥的个人副本。（注意：即使您正在加密密钥的每个副本，维护相同信息的多个副本也可能会出现安全问题。）
不要存储用户密码。相反，散列它根据标准最佳实践（使用盐，等）并存储散列。
当用户提供登录密码时，对其进行哈希处理并与您存储的值进行比较。如果匹配，则使用（明文）密码解密密钥，然后使用该密钥解密实际数据。

传输通过安全连接（例如 SSL）的数据。只要您继续遵循最佳做法，允许用户访问（和修改）他们自己的数据是合理的（也许是必需的）。

8 位密码意味着 10⁸ ~ 2²⁷ = 27 位的密钥空间，按照今天的标准，这是相当糟糕的。如果您不能鼓励使用更长（或字母数字）的密码，您可能需要考虑增加层数。
多层策略（用户提供用于加密“实际”密钥的密码）的一个优点是您可以对用户透明地更改加密密钥，从而满足任何密钥轮换要求..
当您设计安全解决方案时，标准的警告是要记住，即使遵循标准，DIY 安全也是有风险的。您最好使用信誉良好的供应商提供的现成软件包，或者至少让经过培训、认证的安全专业人士对您的策略和实施进行审计。

祝你好运！

【讨论】：

我担心的是，由于 8 个字母数字字符的密码非常糟糕，因此允许使用它们来检索一个用户的帐户信息是一个安全漏洞。但是，它只是一个帐户。并且随着系统正确地进行密码散列，需要蛮力来破解每个用户帐户以获取银行信息-也许这已经足够了。我喜欢 2 和 4 一起工作以允许用户修改自己的信息。但我不清楚如何生成每月提交的批处理文件。同意重新：你自己的角色问题。

评论：