我听过很多关于在数据库中存储哈希密码的原因。然而，在身份验证API中几乎总是有存储明文或加密密码的选项。
是否有理由将密码作为明文或加密文本存储在数据库中呢？
注意：要明确的是，我知道存储非哈希密码几乎总是不好的。（至少据我所知）我的问题是，为什么大多数身份验证API包括将密码存储为加密文本或明文的选项。
为什么您会想要在数据库中存储明文或加密（未哈希）的密码？
5
- Earlz
5
我能想到的唯一原因是客户需求极差。 - David Thomas
3没有任何正当理由。从未如此。在网站上提交忘记密码表单并收到电子邮件显示密码，没有比这更糟糕的事情了。呃。 - Bennor McCarthy
Earlz - 请澄清一下，您是在问为什么连接字符串允许明文密码，还是IIS身份验证？而不是为什么程序员可能会这样做（如果他们知道更好的方法）？ - Kobi
@Kobi 我不是在问连接字符串。我指的是字面上将密码存储在数据库中，而不是连接字符串或任何特定于IIS的东西。 - Earlz
我知道。实际上，编辑已经解释了 - 你不是在问程序员为什么这样做。 - Kobi
9个回答
6
我能想到的一个原因是为了提供密码恢复选项。如果系统不知道密码，就无法恢复密码。
当然，另一种选择是让系统将密码重置为新密码，并将新密码发送给您。
- Andrew Cooper
8
1重置密码应该是更安全的选项。 - Fidi
同意。虽然这是我能想到的唯一理由，但不对密码进行哈希处理。 - Andrew Cooper
1有时候，在一些网站上恢复旧密码就足够了。 - user333306
嗯，你好 - 密码盐？在哈希密码时，你可以生成一个特殊的盐，当密码被遗忘时，这个相同的盐可以用来解密它。这就是(喝口水) ASP.NET Membership 的工作原理。 - RPM1984
盐被用来防止彩虹表攻击，其中哈希值变得已知。如果没有盐，则可以在已知哈希值的彩虹表中查找哈希值并恢复密码。因此，盐实际上使哈希更强大且难以恢复。 - Andrew Cooper
显示剩余3条评论
6
我能想到的唯一真正的原因是当数据库属于一个针对真实应用程序的系统时。比如说，当你有登录某个东西的程序（电子邮件客户端，即时通讯客户端等），所有这些都必须以可恢复的方式存储密码以获得访问权限，因为目标应用程序不会区分“真实用户”和“通过工具的用户”。OAuth等技术正是为了解决这个问题而开发的，以保存用户的密码。
- poke
5
也许你是一名黑客，想要使用或出售它们？
- Kobi
1
即使您相信数据库的安全性非常高，但所有管理员仍然可以访问用户密码。
重要的是要明白，密码加密只能保护您的密码，而不能保护您的网站。
如果您的网站没有足够的保护措施，密码加密也无法防止被破解。如果您的系统被破解，黑客可以对其造成不可修复的损害，并获得访问机密信息（包括密码数据库）的权限。但是，如果您将此信息加密存储，黑客实际上无法利用它。即使在今天的计算机上，破解加密密码需要大量的时间和处理能力。
重要的是要明白，密码加密只能保护您的密码，而不能保护您的网站。
如果您的网站没有足够的保护措施，密码加密也无法防止被破解。如果您的系统被破解，黑客可以对其造成不可修复的损害，并获得访问机密信息（包括密码数据库）的权限。但是，如果您将此信息加密存储，黑客实际上无法利用它。即使在今天的计算机上，破解加密密码需要大量的时间和处理能力。
- Oyeme
1
2那种回答恰好相反于问题的意思 ;) - Bennor McCarthy
1
1）大多数挑战-响应身份验证协议要求服务器知道明文密码。有例外，但它们不受欢迎且难以实现。
2）存储密码允许密码恢复。
- blaze
1
这就是确切的零知识密码证明系统为什么不那么流行的原因。 - Jacco
1
我遇到了以下争论几次：
存储明文密码可以让您检测到用户更改其密码为接近旧密码的内容，例如通过递增数字、添加“1”或通过某些其他低条件熵更新方法。
没有人应该将这个论点视为存储明文密码的好理由-出于多种原因，这是错误的。
存储明文密码可以让您检测到用户更改其密码为接近旧密码的内容，例如通过递增数字、添加“1”或通过某些其他低条件熵更新方法。
没有人应该将这个论点视为存储明文密码的好理由-出于多种原因，这是错误的。
- David Cash
0
当然，您可以将所有密码作为明文存储在您的存储（例如数据库）中。但这不被推荐。如果有人成功入侵您的服务器并从数据库中获取您的数据，则他也会获得每个密码。即使只是使用常见方法（如md5）哈希存储密码，在这种情况下也不太安全。因为有彩虹表（请搜索谷歌），可用于查找密码。
因此，我建议存储盐加密的密码。我不知道为什么您会将密码存储为明文。我不会这样做 :)
- Fidi
0
一个原因可能是为了自动重用密码到另一个外部服务。
如果我配置我的Gmail帐户从其他非Google电子邮件提供商检索我的电子邮件，我必须向Google提供我的密码，并且Google必须以明文形式拥有此密码才能将我的邮件放入我的Gmail帐户中。
这显然不是主要服务的相同密码，但它仍然是“密码类型”的。
- PeterMmm
2
不错的观点，但在这种情况下，提供者存储的是一个密码，而不是它自己的密码。 - Kobi
1OAuth旨在支持此用例，并正在逐渐流行。 - Sripathi Krishnan
0
我所能想到的唯一“好”的理由就是，客户支付你来开发应用，或者你的经理坚持这么做。我无法想出任何技术上的理由。
- GrandmasterB
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接