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

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

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

允许用户检索其原始密码的唯一方法是使用用户自己的公钥对其加密。只有该用户才能解密他们的密码。

步骤如下:

用户在您的站点上注册(当然是通过SSL)而无需设置密码。自动登录或提供临时密码。 您提供存储他们的公共PGP密钥，以便将来检索密码。 他们上传他们的公共PGP密钥。 你让他们设置一个新密码。 他们提交密码。 您使用可用的最佳密码哈希算法(例如bcrypt)哈希密码。在验证下一次登录时使用此选项。 使用公钥加密密码，并单独存储。

如果用户随后询问他们的密码，您将使用加密的(而不是散列的)密码进行响应。如果用户不希望将来能够检索他们的密码(他们只能将其重置为服务生成的密码)，可以跳过步骤3和7。

在独立服务器上打开一个数据库，并给每个需要此功能的web服务器一个加密的远程连接。 它不必是关系DB，它可以是具有FTP访问权限的文件系统，使用文件夹和文件而不是表和行。 如果可以的话，给web服务器只写权限。

像正常人一样，在网站的数据库中存储不可检索的密码加密(让我们称之为“pass-a”):) 对于每个新用户(或密码更改)，在远程DB中存储密码的普通副本。使用服务器id，用户id和“pass-a”作为这个密码的组合密钥。你甚至可以在密码上使用双向加密，这样晚上睡得更好。

现在，为了让某人同时获得密码和它的上下文(站点id +用户id +“pass-a”)，他必须:

入侵网站的数据库，以获得(“pass-a”，用户id)对或对。 从配置文件中获取网站的id 找到并侵入远程密码数据库。

您可以控制密码检索服务的可访问性(仅将其公开为安全的web服务，每天只允许一定数量的密码检索，手动进行，等等)，甚至为此“特殊安全安排”收取额外费用。 密码检索数据库服务器是相当隐藏的，因为它不提供很多功能，可以更好地保护(你可以定制权限，进程和服务紧密)。

总而言之，你让黑客的工作变得更加困难。在任何一台服务器上出现安全漏洞的几率都是一样的，但是有意义的数据(帐户和密码的匹配)将很难组合起来。

密码遗失/忘记处理:

没有人能够恢复密码。

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

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

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

抱歉，但只要你有办法破解他们的密码，就不可能是安全的。痛苦地抗争，如果你输了，CYA。

您可以使用公钥加密密码+盐。对于登录，只需检查存储的值是否等于从用户输入+ salt计算的值。如果需要以明文形式恢复密码，则可以使用私钥手动或半自动地解密。私钥可以存储在其他地方，还可以对称加密(这将需要人工交互来解密密码)。

我认为这实际上有点类似于Windows恢复代理的工作方式。

密码被加密存储 人们无需解密为明文即可登录 密码可以恢复为明文，但必须使用私钥，私钥可以存储在系统之外(如果您愿意，可以存储在银行保险箱中)。