问如何在数据库中安全地存储用户名/密码(散列不起作用)

EN

*(我不是安全或密码专家；这是我根据阅读和研究得出的理解，但与权威建议相去甚远。获取web应用安全专业人员的建议，并进行适当的安全审计。)*

你能做的最好的事情就是当用户没有主动登录时，你的应用程序无法解密它们。

使用部分基于用户原始、未经散列的密码的密钥对凭据进行加密。当然，你永远不会在你的系统上存储用户的密码来登录你的服务，所以你只能在认证过程中短暂地访问它(那是因为web还没有赶上90年代中期，采用了合理的挑战-响应认证方案)。在用户登录时，您可以解密为第三方服务保存的凭证，并将其存储在用户的易失性服务器端会话中。

对于加密密钥，您可以将用户名和用户原始密码与您为每个(用户、第三方凭据)对随机生成的较大的盐值进行散列，并与加密的凭据一起存储。盐应该不同于用于存储哈希密码的盐。

这并不理想，而且有各种各样的问题--但是在用户的会话到期后，用户将无法访问凭据，或者他们登录了我们的会话，而您清除了他们的会话。

这也意味着当他们没有主动登录时，你的应用程序不能代表他们行动，这一限制可能会让你望而却步，这取决于你的需求。

一个较弱的选择是在应用程序重新启动时由sysadmin手动输入的所有用户凭据的密钥。这个密钥必须存储在内存中，但它至少不在磁盘或数据库中，所以有人窃取您数据库的转储文件时，解密存储的凭据会困难得多。

如果攻击者找到一种方法来欺骗你的应用程序在解密后暴露这些域对象，或者让它冒充该用户，让它代表另一个用户在第三方服务上执行操作，等等，这两种选择都不会对你有帮助。

另一个建议是:在应用程序端使用pgcrypto，而不是在数据库中使用加密。这意味着DB永远不会看到解密数据所需的密钥材料；它永远不会泄露到数据库日志中，也不会从pg_stat_activity中嗅探出来，等等。