Security 加密第三方凭据

我有一个应用程序，需要将第三方凭据存储到AmazonS3、FTP、SFTP等服务中

我知道不需要密码就可以访问其中一些系统，但这也有其自身的问题。如果我们的客户让我们通过ACL访问他们的S3存储桶，我们仍然需要验证哪个存储桶属于哪个用户，SFTP和ssh密钥验证也是如此

在可能的情况下，我们将尽最大努力允许使用非密码的替代方案，但有时（FTP）这是不可能的。因此，我正在寻找关于如何在我们的数据库（MySql）或其他地方存储这些敏感数据的建议

在过去，我曾读到有人使用TrueCrypt分区自动卸载，但这可能需要良好的入侵检测。目前，我对简单的方法感兴趣，这些方法可以带来合理的安全性，并且可以在将来加以改进

---

关于这个问题的任何建议都将受到高度重视

有各种各样的可能性，因为在我看来，您没有提供足够的上下文信息，所以我将试着从我的角度给您一个概述。我假设这里最重要的方面是数据的机密性和用户的身份验证。数据的完整性和可用性就不那么重要了

如果您想要基本的安全性，您可以让MySQL通过用户名/密码组合来处理它，并设置给定帐户的访问权限。然而，由于mysql的访问控制机制不是细粒度的（您可以只为每个表设置访问控制规则，而不是每行），这可能会导致糟糕的数据库设计

如果您想采用非密码方式，可以向用户提供客户端证书，并让他们通过出示客户端证书（使用TLS）来证明自己的身份，或者让他们签名（请注意，这是危险的，因为您创建了所谓的签名oracle）

另一种方法是加密数据库中的数据。您可以通过从密码派生对称密钥并使用此数据加密凭据来实现这一点。这里的问题当然是，您的密钥派生协议应该是好的，这不容易实现（因此，如果您选择此项，我建议您采用现有的密钥派生协议或使用streamcipher）。在这里查看streamcipher的列表

---

如果您非常关心安全性，您可以开始考虑一些奇特的解决方案，例如使用智能卡进行身份验证，或者使用时间同步的防篡改设备生成访问代码。但是，请注意，这些奇特的解决方案并不能为您提供免费的安全性，如果实施这些系统既困难又昂贵（由于开发和部署），但是，如果操作正确，它们可以提供最佳的安全性。

请用户在设置帐户时（在提供密码之前）提供（强）密码。然后使用从用户密码的强散列（SHA256或类似内容）派生的密钥加密数据库中该帐户的所有数据。这样，如果您的服务器遭到破坏，则不会显示任何数据，因为这些数据是使用用户密码加密的（好吧，是用户密码的散列），并且该密码不会存储在服务器上的任何位置。

您需要调查密钥存储库的使用情况。TruCrypt就是这样一个密钥库的例子，但这是一个个人密钥库，不用于服务级别凭据

---

你将无法避免将他们的密码存储在一种有人可以访问的格式中，目的是尽量减少谁可以访问这些信息。将MySQL与应用程序数据放在一起会导致灾难。

如果这样做，请小心密码更改：当用户更改密码时（可能是因为他们忘记了密码，或者是因为他们通过自动更改脚本忘记了密码，或者是因为忘记了密码并与人交谈，或者是因为已经30天了，或者其他原因）您需要更新派生密钥和加密数据。同时请记住，在密码重置期间通过电子邮件发送密码会泄露密钥。生成新密码将使以前的所有数据无效。-1在这种情况下，存储哈希与存储密码一样糟糕。如果攻击者获得对散列的访问权，他可以简单地派生密钥并使用该密钥解密帐户数据。您不存储散列。当需要访问时，用户提供他们的密码，然后用于计算用作密钥的散列。然后，密钥用于解密存储在数据库中的凭据，与密钥有关的所有内容都将从内存中清除。如果散列作为键控材料，则永远不要存储散列。