Data Encryption存储大量信用卡信息的数据库是我们刚刚完成的系统的必然部分。 我想要的是卡号的最终安全性，由此我们建立了一种加密和解密的机制，但是我们自己无法解密任何给定的卡号。 我所追求的是一种即使在数据库级别也可以保护此信息的方法，因此没有人可以进入并产生一张卡号文件。 其他人如何克服这个问题？ 什么是"标准"方法？ 至于数据的使用情况，这些链接都是私有和安全的，除了创建记录并对其进行加密之外，不执行卡号的传输，因此我不必担心前端，后端。 好吧，数据库是ORACLE，所以我可以使用PL / SQL和Java。 不乏处理器愿意存储您的CC信息并将其交换为令牌的代币，您可以使用该令牌对存储的号码进行计费。这使您脱离了PCI合规性，但仍允许按需计费。根据需要存储CC的原因，这可能是更好的选择。 大多数公司将其称为"客户档案管理"，实际上在费用上是??相当合理的。 我知道的一些提供者(无特定顺序)：
除非您是付款处理商，否则您实际上不需要存储任何形式的抄送信息。 查看您的要求，实际上没有太多需要存储抄送信息的情况 不要存储信用卡号，而应存储哈希值。当您需要验证新数字是否与存储的数字匹配时，请对新数字进行哈希处理并将其与存储的哈希进行比较。如果它们匹配，则数字在理论上是相同的。 另外，您可以通过让输入卡号的用户输入密码来加密数据。您可以将其用作加密/解密密钥。 但是，任何有权访问您的数据库和源代码的人(即您和您的团队)都会发现解密该数据很简单(即修改实时代码，以便将输入的所有解密密钥通过电子邮件发送到一次性的Hotmail帐户等)。 如果您因为不想让用户重新输入而存储信用卡信息，则任何形式的散列都将无济于事。 您什么时候需要使用信用卡号？ 您可以将信用卡号存储在一个更安全的数据库中，而在主数据库中仅存储足以向用户显示的信息以及对该卡的引用。可以将后端系统锁定得更多，并仅将实际信用卡信息用于订单处理。您可以根据需要通过一些主密码对这些数字进行加密，但是密码必须由获取数字的代码所知道。 是的，您只是解决了一些问题，但是很多安全性更多的是关于减少攻击范围而不是消除攻击范围。如果要消除它，则不要在任何地方存储信用卡号！ 对于电子商务类型的用例(例如Amazon 1-Click)，您可以使用用户现有的强密码对CC(或密钥)进行加密。 假设您仅存储密码的哈希值，则仅存储用户(或彩虹表)，但是必须在每个用户上运行它，并且如果未提供相同的密码，则将不起作用-不仅仅是 1散列相同)可以对其进行解密。 密码更改时，您必须格外小心地重新加密数据，如果他们忘记了密码，数据将毫无价值(并且需要由用户重新输入)-但是，如果付款是由用户发起的 ，那么效果会很好。 如果您使用的是Oracle，则可能对透明数据加密感兴趣。不过，仅提供企业许可证。 Oracle还具有用于加密的实用程序-解密，例如DBMS_OBFUSCATION_TOOLKIT。 对于"标准"，您感兴趣的适当标准是PCI DSS标准，该标准描述了需要采取哪些措施来保护敏感的信用卡信息。 我会对称加密(AES)安全的盐化哈希(SHA-256 + salt)。加盐大的盐就足够了，但是如果数据库而不是代码泄漏，那么加密会增加一点额外的费用，届时或其他方式会有彩虹表用于加盐的哈希。当然，将密钥存储在代码中，而不是数据库中。 值得注意的是，没有什么可以保护您免受弯曲的队友的侵害，例如，他们还可以在哈希之前存储日期的副本。您必须妥善保管代码存储库，并对信用卡处理路径中的所有代码进行频繁的代码修订。此外，还应尽量减少从接收数据到对数据进行加密/散列的时间，以确保从内存中清除了存储数据的变量。 知道数据库服务器和语言/平台类型会很有帮助，这样我们可以更具体一些，但是我将研究SHA。 |
