刚刚看到这个有趣而热烈的讨论。 最让我惊讶的是，很少有人关注以下基本问题:

Q1。用户坚持访问纯文本存储的密码的实际原因是什么?为什么它这么有价值?

用户年龄大或小的信息并不能真正回答这个问题。但是，如果没有正确理解客户的关注点，如何做出业务决策呢?

为什么这很重要呢? 因为如果客户要求的真正原因是系统难以使用，那么解决具体原因可能会解决实际问题?

由于我没有这些信息，也无法与这些客户交谈，我只能猜测:这是关于可用性的，见上文。

我看到的另一个问题是:

Q2。如果用户一开始就不记得密码，为什么旧密码很重要?

这是可能的答案。 如果你有一只叫“miaumiau”的猫，用她的名字作为密码，但忘记了，你是更愿意被提醒它是什么，还是更愿意被发送像“#zy*RW(ew)”这样的信息?

另一个可能的原因是，用户认为想出一个新密码是一项艰巨的工作!所以，把旧密码发送回去给她一种错觉，让她不用再去做那件痛苦的工作了。

我只是想知道原因。但无论原因是什么，必须解决的是原因而不是原因。

作为用户，我希望事情简单!我不想努力工作!

如果我登录一个新闻网站看报纸，我想输入1111作为密码，然后就可以通过了!!

我知道这是不安全的，但我在乎别人访问我的“帐户”吗?是的，他也会看新闻!

网站是否存储我的“私人”信息? 我今天读的新闻? 那就是网站的问题，不是我的! 站点是否向已验证的用户显示私人信息? 那就先别表现出来!

这只是为了说明用户对问题的态度。

总之，我不认为这是一个如何“安全地”存储纯文本密码的问题(我们知道这是不可能的)，而是如何解决客户实际关心的问题。

将用户安全问题的答案作为加密密钥的一部分，并且不要将安全问题答案存储为纯文本(而是散列)

Michael Brooks一直对cwe257直言不讳——事实上，无论您使用什么方法，您(管理员)仍然可以恢复密码。那么下面这些选项怎么样:

使用其他人的公钥(一些外部授权机构)加密密码。这样，您就不能亲自重建密码，用户必须去外部权威机构要求恢复他们的密码。 使用从第二个口令短语生成的密钥加密密码。在客户端进行加密，绝不将其明文传输到服务器。然后，为了恢复，通过从他们的输入重新生成密钥，再次在客户端解密。不可否认，这种方法基本上是使用第二个密码，但您总是可以告诉他们把它写下来，或者使用旧的安全问题方法。

我认为1。是更好的选择，因为它允许您在客户的公司内指定某人持有私钥。确保他们自己生成密钥，并将其与指示一起存储在保险箱等。您甚至可以通过选择只加密密码并向内部第三方提供密码中的某些字符来增加安全性，这样他们就必须破解密码才能猜测它。将这些字符提供给用户，他们可能会记住它是什么!

密码遗失/忘记处理:

没有人能够恢复密码。

如果用户忘记了密码，他们至少必须知道自己的用户名或电子邮件地址。 根据请求，在Users表中生成GUID，并向用户的电子邮件地址发送包含GUID作为参数的链接的电子邮件。

链接后面的页面验证参数guid是否真的存在(可能带有一些超时逻辑)，并要求用户输入新密码。

如果您需要热线帮助用户，请向授予模型中添加一些角色，并允许热线角色临时以已识别的用户登录。记录所有此类热线登录。例如，Bugzilla为管理员提供了这样的模拟功能。

另一个你可能没有考虑到的选择是允许通过电子邮件进行操作。这有点麻烦，但我为一个客户端实现了这个功能，该客户端需要系统“外部”的用户来查看(只读)系统的某些部分。例如:

一旦用户注册，他们就拥有完全的访问权限(就像普通用户一样) 网站)。注册必须包括电子邮件。 如果需要数据或操作，而用户不需要 记住他们的密码，他们仍然可以通过 点击一个特殊的“给我发邮件以获得许可”按钮，就在常规的“提交”按钮旁边。 然后，请求以超链接发送到电子邮件，询问他们是否希望执行该操作。这类似于密码重置电子邮件链接，但它不是重置密码，而是执行一次性操作。 然后用户点击“Yes”，它确认应该显示数据，或者应该执行操作，显示数据等等。

正如你在评论中提到的，如果电子邮件被泄露，这将不起作用，但它确实解决了@joachim关于不想重置密码的评论。最终，他们将不得不使用密码重置，但他们可以在更方便的时候这样做，或者根据需要在管理员或朋友的帮助下这样做。

该解决方案的另一种方法是将操作请求发送给第三方可信管理员。这对于老年人、智障人士、非常年轻或其他困惑的用户来说效果最好。当然，这需要一个可信的管理员来支持这些人的行动。

在回答这个问题时，已经有很多关于用户安全问题的讨论，但我想再提一下好处。到目前为止，我还没有看到在系统中存储可恢复密码的合法好处。考虑一下:

通过电子邮件发送密码对用户有好处吗?不。他们从一次性密码重置链接中获益更多，这有望让他们选择一个他们能记住的密码。 在屏幕上显示密码对用户有好处吗?不，原因和上面一样;他们应该选择一个新密码。 让技术支持人员告诉用户密码对用户有好处吗?没有;同样，如果支持人员认为用户的密码请求已经过正确验证，那么为用户提供新密码和更改密码的机会对用户更有利。此外，电话支持比自动密码重置更昂贵，所以该公司也没有受益。

从可恢复的密码中获益的似乎只有那些怀有恶意的人，或者那些需要第三方密码交换的糟糕api的支持者(请永远不要使用这些api !)也许你可以通过如实向客户陈述公司存储可恢复密码没有获得任何好处，只会承担责任来赢得争论。

从这类请求的字里行间，您会发现客户端可能根本不理解，甚至根本不关心密码是如何管理的。他们真正想要的是一个对用户来说并不难的认证系统。所以，除了告诉他们其实他们并不想要可恢复的密码之外，你还应该为他们提供一些让认证过程不那么痛苦的方法，尤其是如果你不需要像银行这样的高安全级别:

允许用户使用他们的电子邮件地址作为用户名。我见过无数用户忘记自己的用户名，但很少有人忘记自己的电子邮件地址。 提供OpenID，让第三方支付用户遗忘的成本。 放宽密码限制。我敢肯定，当一些网站因为“不能使用特殊字符”或“您的密码太长”或“您的密码必须以字母开头”之类无用的要求而不允许您使用首选密码时，我们都非常恼火。此外，如果易用性比密码强度更重要，您甚至可以通过允许更短的密码或不要求混合字符类来放松不愚蠢的要求。随着限制的放松，用户将更有可能使用他们不会忘记的密码。 不要让密码过期。 允许用户重新使用旧密码。 允许用户选择自己的密码重置问题。

但如果你出于某种原因(请告诉我们原因)真的，真的，真的需要一个可恢复的密码，你可以通过给他们一个非密码认证系统来保护用户，以免他们的其他在线帐户受到潜在的威胁。因为人们已经熟悉用户名/密码系统，这是一个行之有效的解决方案，这将是最后的手段，但肯定有很多创造性的替代密码的方法:

让用户选择一个数字引脚，最好不要是4位，最好只在防止暴力尝试的情况下。 让用户选择一个只有他们自己知道的简短答案的问题，这个问题永远不会改变，他们会一直记住，而且他们不介意其他人发现。 让用户输入一个用户名，然后画一个容易记住的形状，并有足够的排列来防止猜测(看看这张G1如何解锁手机的漂亮照片)。 对于一个儿童网站，你可以根据用户名(有点像身份)自动生成一个模糊的生物，并要求用户给这个生物一个秘密的名字。然后他们会被提示输入该生物的秘密名称来登录。