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

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

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

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

步骤如下:

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

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

我以实现多因素身份验证系统为生，所以对我来说，很自然地认为可以重置或重构密码，同时暂时少使用一个因素来验证用户，仅用于重置/重新创建工作流。特别是使用otp(一次性密码)作为一些额外的因素，如果建议的工作流的时间窗口很短，则可以降低很大程度的风险。我们为智能手机(大多数用户已经随身携带了一整天)实现了软件OTP生成器，并取得了巨大的成功。在对商业插头的抱怨出现之前，我想说的是，当密码不是用于验证用户身份的唯一因素时，我们可以降低密码易于检索或重置的固有风险。我承认，在网站场景之间的密码重用情况仍然不太好，因为用户会坚持拥有原始密码，因为他/她也想打开其他网站，但你可以尝试以最安全的方式(htpps和谨慎的html外观)提供重建的密码。

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

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

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

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

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

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

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

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

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

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