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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

保护凭证不是一个二进制操作:安全/不安全。安全是关于风险评估的，是在连续统上衡量的。安全狂热分子讨厌这样想，但丑陋的事实是，没有什么是完全安全的。具有严格的密码要求、DNA样本和视网膜扫描的散列密码更安全，但以开发和用户体验为代价。明文密码的安全性要低得多，但实现起来成本更低(但应该避免使用)。在一天结束的时候，它归结为一个漏洞的成本/收益分析。您可以根据所保护的数据的值及其时间值来实现安全性。

一个人的密码泄露到野外的代价是什么?给定系统中模拟的成本是多少?对于联邦调查局的电脑来说，代价可能是巨大的。对于Bob的一次性5页网站来说，成本可以忽略不计。专业人员为客户提供选项，并在涉及到安全性时列出任何实现的优势和风险。如果客户要求的某些东西可能会使他们处于风险之中，因为他们未能遵守行业标准，那么情况就会加倍。如果客户明确要求双向加密，我将确保您记录您的反对意见，但这不应该阻止您以您所知道的最佳方式实现。说到底，这是客户的钱。是的，你应该推动使用单向哈希，但说这绝对是唯一的选择，其他任何东西都是不道德的，这完全是无稽之谈。

如果您使用双向加密存储密码，安全性就归结于密钥管理。Windows提供了一些机制来限制对管理帐户和密码的证书、私钥的访问。如果你在其他平台上托管，你需要看看你在那些平台上有什么可用的选项。正如其他人建议的那样，您可以使用非对称加密。

据我所知，没有法律(包括英国的数据保护法案)明确规定密码必须使用单向哈希存储。这些法律中唯一的要求就是采取合理的措施保证安全。如果对数据库的访问受到限制，那么在这种限制下，即使是明文密码也可以合法地使用。

然而，这确实揭示了另一个方面:法律优先权。如果法律优先级建议您必须根据构建系统的行业使用单向散列，那么情况就完全不同了。这是你用来说服你的客户的弹药。除此之外，最好的建议是提供合理的风险评估，记录您的反对意见，并以您可以满足客户要求的最安全的方式实施系统。