我正在开发针对非技术用户的应用程序。我希望有大量关于丢失密码和无法登录的支持电话。
我正在使用ASP.NET成员资格提供程序，它提供了3个用于存储密码的选项 - 明文，哈希，加密。
鉴于此应用程序的性质，以明文形式存储密码是一个好主意吗？以明文形式存储密码是否涉及法律问题？
答案 0 :(得分：67)
从不。
永远不会有从未有充分理由在您的数据库中存储密码。特别是不明文。您应该存储密码 的哈希。
您可以对用户执行的最差事件是通过明文电子邮件在Internet上广播其“已恢复”的密码。 如此简单只需存储无法恢复的密码的单向哈希。
对于丢失的密码，您只需重置他们的密码并为他们提供一个临时密码，他们必须在登录时更改密码。安全可靠。
人们经常对多个应用程序使用相同的密码（尤其是非技术用户）。因此您的应用程序可能包含人们银行帐户的密码，电子邮件等。
您有责任来保护用户的密码，无论您的应用程序多么简单。
答案 1 :(得分：19)
以下是使用未加密密码的几个原因：
如果您认为其中任何一项与您的商业模式相符，请继续并保持密码未加密。
答案 2 :(得分：11)
不，永远不是一个好主意，无论你的申请多么愚蠢。
答案 3 :(得分：9)
如果您希望自己的网站被黑，而且必须保证您的用户数据被盗或损坏。
当您以明文形式存储密码时。
答案 4 :(得分：3)
我认为有一种情况是以明文形式存储密码是合适的。
如果您正在编写一个应用程序，以便在如何编写安全代码的演示中用作“之前”示例，以便您可以展示如何实现密码加密/散列技术。
答案 5 :(得分：2)
将密码存储在数据库中永远不是一个好主意。存储密码哈希（可能是盐渍的）。如果密码丢失，请生成一个新密码并将其发送到经过验证的电子邮件地址 - 确保他们在下次登录时更改此自动生成的密码。
您的目标受众可能不属于技术人员，但他们的朋友是休闲/专业恶作剧者的情况并非如此。非技术用户必须格外小心，因为他们更有可能为您的小型应用程序，Google帐户和网上银行帐户（如果银行接受该密码）保留相同的用户名/密码组合。他们将失去他们的数据/邮件账户/金钱，你将失去信任和客户。
这是一篇关于storing passwords in databases的博客文章，值得@codinghorror
阅读答案 6 :(得分：1)
从不。 “申请的性质”无关紧要。您应该问自己，您认为以明文形式存储它的好处是什么。您是否希望技术支持人员拿起电话并告诉他们密码？或者当他们忘记时通过电子邮件发送给他们？那些从来都不是好主意。
已建立密码设计模式：
这是概述，这是预期的方法。存在其他变体，例如提供安全性问题。
答案 7 :(得分：1)
有关法律原因的任何可靠信息，请咨询律师。在美国，您应该可以从当地律师协会获得推荐。我不是律师，这不是法律建议。
也就是说，如果您有数据泄露事件，您可能需要对您网站上发生的任何事情承担责任，包括对任何财务或自由行为负责的可能性。如果用户在多个站点上使用密码，您可能需要对其他站点上的其他活动负责。在美国，你几乎可以起诉任何东西，而且我不清楚你会赢得这样的诉讼。
因此，法律责任可能很大。保存明文密码前请咨询律师。
答案 8 :(得分：1)
安全性和可用性是同一根棍子的两端。当您使应用程序易于使用时，例如向用户提供密码，则会使其不安全。当您提交申请时，如果爱因斯坦会忘记5个问题，血液样本和密码，那么您就会遇到可用性问题。
答案 9 :(得分：0)
如果您从用户角度考虑可用性并减少工作量，那么这是一个好主意。
但是，您必须明白，作为开发人员，您需要保证用户在线安全。用户想要的并不总是对他们最好。
人们在很多帐户中使用相同的密码。如果您的数据库在某种程度上受到了损害，那么您就会泄露可以在银行帐户中使用的密码。
如果您认为重置密码不适用于非技术人员，请至少创建一个表单来更改密码，例如Gmail。
我不知道在美国，但至少在我的国家，如果受损系统将我的密码存储在其中，我会尝试起诉他们，因为我们有方法来阻止存储清除文字密码。
答案 10 :(得分：0)
只有当您希望任何人都能轻松获取密码时，您才能以明文形式存储密码。对于您的用例，我建议一个选项，用户输入他们的电子邮件并获取一个包含他们可以登录的链接的电子邮件。登录后，如果他们愿意，他们可以选择更改密码，但如果大多数用户不是常客，他们甚至可能不想更改密码，因为他们会在下次访问前忘记密码。
答案 11 :(得分：0)
说真的，我认为这不是一个好主意......