存储大量信用卡信息的数据库是我们刚刚完成的系统的必然部分。我想要的是卡号的最终安全性，由此我们建立了一种加密和解密的机制，但是我们自己无法解密任何给定的号码。

我所追求的是一种即使在数据库级别也可以保护此信息的方法，因此没有人可以进入并生成文件卡号。其他人如何克服这个问题？什么是"标准"方法？

至于数据的使用情况，这些链接都是私有和安全的，除了创建记录并对其进行加密之外，不执行卡号的传输，因此我不担心前端而是后端。

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

解决方案

回答

知道数据库服务器和语言/平台类型将很有帮助，这样我们可以更具体一些，但是我将研究SHA。

回答

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

另外，我们可以通过让输入卡号的用户输入密码来加密数据。我们可以将其用作加密/解密密钥。

但是，任何有权访问数据库和源代码的人(即我们和团队)都会发现解密该数据很简单(即修改实时代码，以便将输入的所有解密密钥通过电子邮件发送到一次性的Hotmail帐户等)。

回答

如果我们使用的是Oracle，则可能对透明数据加密感兴趣。不过，仅适用于企业许可证。

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

至于"标准"，我们感兴趣的适当标准是PCI DSS标准，该标准描述了需要采取哪些措施来保护敏感的信用卡信息。

回答

我会对称加密(AES)一个安全的盐化哈希(SHA-256 + salt)。加盐大的盐就足够了，但是如果数据库而不是代码泄漏了，那么加密会增加一点额外的费用，届时或者其他方式会有彩虹表用于加盐的哈希。当然，将密钥存储在代码中，而不是存储在数据库中。

值得注意的是，没有什么可以保护我们免受弯曲的队友的侵害，例如，他们还可以在哈希之前存储日期的副本。我们必须妥善保管代码存储库，并对信用卡处理路径中的所有代码进行频繁的代码修订。此外，还应尽量减少从接收数据到对数据进行加密/散列的时间，以确保从内存中清除了存储数据的变量。

回答

这就是我们的工作：数据库中如何加密敏感数据？这样，即使我们窃取了我们的Web +数据库服务器，也无法对其进行解密

回答

如果我们因为不想让用户重新输入而存储信用卡信息，那么任何形式的散列都将无济于事。

我们什么时候需要使用信用卡号？

我们可以将信用卡号存储在一个更安全的数据库中，而在主数据库中仅存储足以向用户显示的信息以及对该卡的引用。可以将后端系统锁定得更多，并仅将实际信用卡信息用于订单处理。我们可以根据需要通过一些主密码对这些数字进行加密，但是必须通过需要获取数字的代码才能知道该密码。

是的，我们只是解决了一些问题，但是很多安全性更多的是关于减少攻击范围而不是消除攻击范围。如果要消除它，则不要在任何地方存储信用卡号！

回答

除非我们是付款处理者，否则我们实际上并不需要存储任何形式的抄送信息。

查看要求，实际上没有太多需要存储抄送信息的情况

回答

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

大多数公司将其称为"客户档案管理"，实际上在费用上是​​相当合理的。

我知道的一些提供者(无特定顺序)：

• 授权.NET客户信息管理器
• TrustCommerce城堡
• 脑树

回答

对于电子商务类型的用例(例如Amazon 1-Click)，我们可以使用用户现有的强密码对CC(或者密钥)进行加密。假设我们仅存储密码的哈希，则仅存储用户(或者彩虹表)，但必须在每个用户上运行该密码，并且如果未提供相同的密码而不是仅包含1个密码，则该密码将不起作用哈希相同)可以解密它。

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

回答

我会尝试解释一下，但是这篇文章做得很好。

http://www.di-mgt.com.au/cryptoCreditcard.html