关于安全性:为什么要在数据库中存储纯文本或加密(非散列)密码?

Why would you ever want to store a plain-text or encrypted(not hashed) password in a database?

我听说过在数据库中存储哈希密码的很多原因。然而,在身份验证API中,几乎总是有将密码存储为纯文本或加密的选项。

您是否有理由将密码存储为纯文本或在数据库中加密?

请注意,我知道存储非哈希密码几乎总是不好的。(据我所知)我的问题是,为什么大多数身份验证API都包含将密码存储为加密或纯文本的选项。


我能想到的唯一真正原因是当数据库属于一个本身就是针对真实应用程序的系统时。比如当你有程序为你登录某个东西(电子邮件客户端、即时消息客户端等)。所有这些都必须以一种可恢复的方式存储密码才能获得访问权限,因为目标应用程序不会通过工具来决定真正的用户和用户。但此时,OAuth和Alikes正是用来保存用户密码的。


我能想到的一个原因是允许密码恢复选项。无法恢复系统不知道的密码。

当然,另一种方法是系统只需将密码重置为新密码,然后向您发送新密码。


也许你是个黑客,想用还是卖?It'll be hilarious the first few times this happens.


我遇到过以下几次争论:

存储明文密码允许您检测用户何时将其密码更改为接近旧密码的密码,即通过增加数字、添加"1"或通过其他低条件熵更新方法。

任何人都不应该把这个论点当作存储纯文本密码的一个好理由——它被误导的原因有几个。


1)大多数质询响应认证协议要求服务器知道明文密码。也有例外,但它们不受欢迎,而且很难实现。

2)存储密码允许密码恢复。


即使您十分确定数据库的安全性,所有管理员仍然可以访问您的用户密码。

重要的是要了解密码加密不会保护您的网站,它只能保护您的密码。

如果您的网站没有足够的保护,密码加密将不会使其安全地进行破解。如果您的系统被破解,黑客会对其造成不可弥补的损害,并且还可以访问机密信息,包括密码数据库。但是,如果您将这些信息加密存储,黑客实际上无法利用它。破解加密密码需要大量的时间和处理能力,即使在当今的计算机上也是如此。


我能想到的唯一"好"的原因是客户付钱给你开发这个应用程序,或者你的经理坚持这样做。我想不出任何技术原因。


一个原因可能是自动为另一个外部服务重用密码。

如果我将我的Gmail帐户配置为从其他非Google电子邮件提供商处检索电子邮件,我必须向Google提供密码,而Google必须清除此密码才能将我的邮件导入我的Gmail帐户。

这显然与主服务的密码不同,但无论如何,它是"密码类型"。


当然,您可以将所有密码以纯文本形式存储在存储中(例如数据库)。但不建议这样做。如果有人设法入侵你的服务器,从数据库中获取你的数据,他也会得到所有密码。在这种情况下,即使只存储使用MD5等常用方法散列的密码,也不算完全保存。因为有彩虹表(在谷歌搜索这个),以查找密码。

所以我建议你存储盐密码。我不知道你为什么要把密码存储为纯文本。我不会这么做的:)