database - 数据加密

Question

存储大量信用卡信息的数据库是我们刚刚完成的系统中不可避免的一部分。我想要的是卡号的最终安全性，我们设置了一种机制来加密和解密，但我们自己无法解密任何给定的号码。

我所追求的是一种即使在数据库级别也能保护这些信息的方法，这样任何人都无法进入并生成卡号文件。其他人是如何克服这个问题的？对此的“标准”方法是什么？

至于数据的使用情况，链接都是私密且安全的，除了创建记录并加密时，不会执行卡号的传输，所以我不担心前端只是后端。

好吧，数据库是 ORACLE，所以我可以使用 PL/SQL 和 Java。

score 8 · Accepted Answer

不乏愿意存储您的 CC 信息并将其交换为令牌的处理器，您可以使用该令牌对存储的号码进行计费。这使您摆脱了 PCI 合规性，但仍允许按需计费。根据您需要存储 CC 的原因，这可能是一个更好的选择。

大多数公司将此称为“客户资料管理”，实际上费用相当合理。

我知道的一些供应商（排名不分先后）：

score 5 · Accepted Answer

除非您是支付处理器，否则您实际上不需要存储任何类型的抄送信息。

查看您的要求，您需要存储CC信息的情况确实不多

score 4 · Accepted Answer

不要存储信用卡号，而是存储哈希值。当您需要验证新数字是否与存储的数字匹配时，请获取新数字的哈希值并将其与存储的哈希值进行比较。如果它们匹配，则数字（理论上）相同。

或者，您可以通过让输入卡号的用户输入密码来加密数据；您可以将其用作加密/解密密钥。

但是，任何有权访问您的数据库和源代码的人（即您和您的团队）都会发现解密该数据是微不足道的（即修改实时代码，以便将输入的任何解密密钥通过电子邮件发送到一次性 Hotmail 帐户等）。

score 3 · Accepted Answer

如果您存储信用卡信息是因为您不希望用户重新输入它，那么任何形式的散列都无济于事。

您什么时候需要对信用卡号采取行动？

您可以将信用卡号存储在更安全的数据库中，并且在主数据库中只存储足够的信息以显示给用户，以及对卡的引用。后端系统可以更加锁定并使用实际的信用卡信息来处理订单。如果您愿意，您可以通过一些主密码来加密这些数字，但密码必须由需要获取数字的代码知道。

是的，您只是稍微改变了问题，但很多安全性更多的是减少攻击足迹，而不是消除它。如果您想消除它，请不要将信用卡号存储在任何地方！

score 1 · Accepted Answer

对于电子商务类型的用例（想想 Amazon 1-Click），您可以使用用户现有的强密码加密 CC（或密钥）。假设您只存储密码的哈希值，只存储用户（或彩虹表 - 但是，它必须在每个用户上运行，并且如果它没有提供相同的密码就无法工作 - 不仅仅是1 哈希相同）可以解密它。

当密码更改时，您必须小心重新加密数据，如果他们忘记密码，数据将毫无价值（并且需要用户重新输入） - 但是，如果付款是用户发起的，那么它会很好地工作。

score 1 · Accepted Answer

如果您使用 Oracle，您可能对透明数据加密感兴趣。但仅适用于企业许可证。

Oracle 还具有用于加密-解密的实用程序，例如DBMS_OBFUSCATION_TOOLKIT。

至于“标准”，您感兴趣的正确标准是PCI DSS标准，该标准描述了需要采取哪些措施来保护敏感的信用卡信息。

score 0 · Accepted Answer

了解数据库服务器和语言/平台类型会很有帮助，这样我们就可以更具体，但我会研究SHA。

score 0 · Accepted Answer

我会对称加密（AES）一个安全的加盐哈希（SHA-256 + salt）。加盐散列对于大盐就足够了，但是加密会增加一些额外的东西，以防数据库而不是代码泄漏，并且到那时或其他方式有加盐散列的彩虹表。当然，将密钥存储在代码中，而不是数据库中。

值得注意的是，没有什么可以保护您免受不正当的队友的伤害，例如，他们还可以在散列之前存储日期的副本。您必须妥善保管代码存储库，并对信用卡处理路径中的所有代码进行频繁的代码修订。还要尽量减少接收数据并对其进行加密/散列处理的时间，手动确保将存储它的变量从内存中清除。

8 回答 8