Database 当您确实需要在数据库中存储密码时，最佳做法是什么

我有一个使用HMAC验证已签名请求的web服务。在这个场景中，有一个密钥（密码）分配给我服务的每个调用者。用户当然会获得该密钥，但我还需要将该密钥存储在数据库中，以便我的服务能够验证传入的每个请求的签名

因此，在这种情况下，我确实需要在数据库中以一种可以检索和使用的形式存储密码。我不能使用在数据库中只存储密码的盐散列的最佳实践

我可以加密密钥，但我需要将加密密钥存储在某个地方。对于安全的RESTful web服务来说，这是一个相当常见的场景，因此像Amazon（AWS）和Microsoft（Azure）这样的公司必须处理这个问题

---

这种情况下的最佳做法是什么？

在数据库中存储密码的唯一时间是连接到其他系统时是否需要密码。如果只需要检查其他实体提供的凭据，则应存储密码的散列

---

即使有必要使用密码与另一方连接，如果您需要一些其他凭据来执行此类访问（例如，有人登录到您的系统，然后您代表他们登录到另一个系统），在实际情况下，最好存储使用提供的密码哈希加密的外部密码（但与存储在数据库中的哈希不同！）。如果有多个凭据可用于登录到您的服务器，请为远程密码存储一个单独的加密密钥副本，并使用每个可接受的凭据进行加密。

如果您确实需要密码，您的场景的最佳做法似乎是使用公钥加密（例如，为了连接到另一个系统），我建议将其放在远离其他信息的地方。可能是另一个数据库，文件系统上的加密文件，等等。因此，如果有人获取了您的主数据库，则不保证他们也会获取有问题的密码

---

这可能很明显，但您希望使用另一个密钥对密码的位置进行加密（以减少以某种方式访问主数据源的人也会访问密码数据存储的可能性）.

存储加密密钥有什么问题？我最近写了一篇关于基本密码存储的博客文章：我对存储加密密钥的评论只是为了解决这样一个事实，即我需要以某种方式保护加密密钥。这有点像鸡蛋。我想不出任何其他方法来处理它，所以问题变成了如何保护加密密钥重新设置加密密钥。是否可以使用用户密码的哈希值对请求进行签名？然后您可以使用存储在数据库中的哈希值，并更符合最佳做法。这是可能的，但我不认为它有多大作用。在这种情况下，密码实际上只是一个随机字节流。如果我对它进行哈希，然后使用我们e签名请求的散列我仍然需要存储散列。如果散列被破坏，将允许有人伪造请求。这无法避免我需要访问调用方用于签名请求的同一字节数组的问题。我不同意。我的情况显然是，我确实需要原始密码来执行签名验证。t嘿，用密钥签署了一个请求，我需要执行相同的签名过程并比较两个散列。因此，在这种情况下，我不需要连接到其他系统，但我确实需要存储密码。签名的非对称加密性能不够，因此我们必须使用共享密钥。如果必须使用需要如果双方都有相同的凭证，您可能会被卡住。特定的密码是只在一个地方使用，还是可以在多个地方使用？如果是后者（例如，如果密码是ASCII文本），可以通过使用ASCII密码的盐散列而不是密码本身来提高安全性。泄露数据库的人可以攻击客户端以接受预散列值，但该值只会泄露一个系统，而不是使用相同ASCII密码的所有系统。这是一个有效点，但在这种情况下是不对称的签名的加密性能不够。@BrettRobi：使用非对称加密发送用于加密签名的对称加密密钥如何？这通常会解决性能问题。