临时密码安全 - 以纯文本形式存储答案

【问题标题】：Temporary Password Security - Storing as Plain Text临时密码安全 - 以纯文本形式存储
【发布时间】：2013-10-18 22:56:58
【问题描述】：

将临时/机器生成的密码作为明文存储在数据库中会有多大的安全问题？

我了解密码应使用带盐的单向哈希函数进行加密。对于用户提供的密码尤其如此，因为用户通常会一遍又一遍地重复使用它们。如果数据库被盗，窃贼可能能够访问 3 方网站上的用户帐户，例如：水电费、社交网络，甚至潜在的网上银行。

将临时/机器生成的“欢迎”或“重置”密码作为明文存储在数据库中会有多大问题？密码将通过电子邮件发送给用户，并且必须在登录时更改。然后他们提供的密码将被散列。

我问的原因是有一些很好的属性可以将临时密码存储为明文。例如，如果用户没有收到“欢迎”或“重置”电子邮件，管理员可以快速查找他们的临时密码。

由于临时密码是机器生成的，如果数据库被盗，窃贼将无法访问用户登录的任何第三方网站。然而，小偷将能够登录生成临时密码的应用程序。

为这些密码分配一个小的“过期时间”会限制暴露，但总的来说，我只是想看看这种方法会有多危险。

【问题讨论】：

【解决方案1】：

您甚至不应该以纯文本形式存储机器生成的密码。

让我们看看攻击者可以做什么，如果他以某种方式仅通过 SQL 注入获得对您的数据库的读取访问权限（我做了一个小的demo SQL 注入有多容易，只需单击下一个箭头即可获得恶意输入）。

具有读取权限的攻击者可以要求为他喜欢的任何电子邮件地址重置密码。因为他可以在数据库中看到新生成的令牌，所以他可以用这个令牌调用重置页面，因此可以更改这个用户的密码。不用说，他现在可以冒充原始用户了。

像处理其他密码一样处理令牌，即使它不能在其他站点上使用。用户帐户可访问的数据可能包含其他数据（如生日、真实姓名），可用于入侵其他网站。

【讨论】：

我想我知道这是个坏主意，但我想看看我能摆脱什么。谢谢:)
@martinstoeckli 我知道这已经有一段时间了，但是您是否碰巧有一个建议来处理没有那个陷阱的密码恢复？我们的 CMS 曾经通过电子邮件向用户发送纯文本密码，我将其升级为使用他们的电子邮件地址向他们发送重置链接，但可以通过查看数据库手动重新创建链接。我不知道如何解决这个问题。
@Toni - 重置链接通常使用强随机标记（20 个字符）。与弱用户密码相比，存储令牌的快速哈希 (SHA-256) 而不加盐是绝对安全的。这使得令牌可以在数据库中搜索，您从请求中获取令牌，再次计算哈希并在数据库中搜索它。我试图在我主页上的article 中更详细地解释这一点。
谢谢，我现在明白了。我不知道我怎么没想到的！

【解决方案2】：

您绝对不能将密码存储在数据库中，更不用说纯文本了。您应该存储它们的哈希值。请参阅this answer 了解原因。然后，您需要围绕该事实构建所有密码重置工具。另请参阅 this answer 了解密码重置功能。

【讨论】：