我应该如何合乎道德地处理用户密码存储，以便以后进行明文检索？

中途之家怎么样？

使用强加密存储密码，并且不要启用重置。

允许发送一次性密码（必须在首次登录后立即更改），而不是重置密码。然后，让用户更改为他们想要的任何密码（如果他们选择，则为前一个密码）。

您可以将其作为重置密码的安全机制“出售”。

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

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

• 密码以加密方式存储
• 人们可以在不解密为明文的情况下登录
• 密码可以恢复为明文，但只能使用私钥，该私钥可以存储在系统外部（如果需要，可以存储在银行保险箱中）。

对不起，但只要你有办法解码他们的密码，它就不可能是安全的。苦战，如果你输了，CYA。

我认为你应该问自己的真正问题是：“我怎样才能更好地说服别人？

不要放弃。你可以用来说服你的客户的武器是不可否认性。如果您可以通过任何机制重建用户密码，那么您已经为他们的客户提供了合法的不可否认性机制，他们可以拒绝依赖于该密码的任何交易，因为供应商无法证明他们没有重建密码并自行进行交易。如果密码被正确地存储为摘要而不是密文，这是不可能的，因为最终客户端要么自己执行了交易，要么违反了他对密码的注意义务。无论哪种情况，这都将责任完全归咎于他。我曾经处理过数亿美元的案件。不是你想弄错的事情。

将用户安全问题的答案作为加密密钥的一部分，并且不要将安全问题答案存储为纯文本（改为哈希）

Michael Brooks 对 CWE-257 直言不讳——无论您使用哪种方法，您（管理员）仍然可以恢复密码。那么这些选项怎么样：

1. 使用其他人的公钥加密密码 - 一些外部权威。这样你就无法亲自重建它，用户将不得不去外部机构要求恢复他们的密码。
2. 使用从第二个密码生成的密钥加密密码。在客户端执行此加密，切勿将其明文传输到服务器。然后，要恢复，请通过从其输入重新生成密钥来再次执行解密客户端。诚然，这种方法基本上是使用第二个密码，但您始终可以告诉他们将其写下来，或者使用旧的安全问题方法。

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

处理丢失/忘记的密码：

任何人都不应该能够恢复密码。

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

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

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

想象一下，有人委托建造了一座大型建筑——比方说，一个酒吧——并发生了以下对话：

建筑师：对于这种规模和容量的建筑，你需要在这里、这里和这里设置消防通道。
客户：不，这太复杂了，维护成本太高了，我不想要任何侧门或后门。
建筑师：先生，消防通道不是可选的，根据城市的消防法规是必需的。
客户：我不是付钱给你争论的。按照我的要求去做。

然后，建筑师会问如何合乎道德地建造这座没有消防通道的建筑吗？

在建筑和工程行业，对话最有可能这样结束：

建筑师：如果没有消防通道，这栋建筑就无法建造。你可以去找任何其他有执照的专业人士，他会告诉你同样的事情。我现在要走了;当你准备好合作时，给我回电话。

计算机编程可能不是一个有执照的职业，但人们似乎经常想知道为什么我们的职业没有得到与土木或机械工程师相同的尊重——好吧，不要再看了。这些职业，当被交给垃圾（或完全危险）的要求时，只会拒绝。他们知道这不是说“好吧，我尽力了，但他坚持，我必须按照他说的去做”的借口。他们可能会因为这个借口而失去执照。

我不知道你或你的客户是否是任何上市公司的一部分，但以任何可恢复的形式存储密码会导致你无法通过几种不同类型的安全审计。问题不在于某些可以访问您的数据库的“黑客”恢复密码有多困难。绝大多数安全威胁都是内部威胁。您需要防止的是一些心怀不满的员工带着所有密码离开并将它们出售给出价最高的人。使用非对称加密并将私钥存储在单独的数据库中绝对不能防止这种情况;总会有人可以访问私有数据库，这是一个严重的安全风险。

没有道德或负责任的方式以可恢复的形式存储密码。时期。

根据我对这个问题的评论：
几乎每个人都非常掩盖了重要的一点......我最初的反应与@Michael Brooks非常相似，直到我意识到，就像@stefanw一样，这里的问题是需求被破坏了，但这就是它们。
但后来，我突然想到，情况可能并非如此！这里缺少的一点是应用程序资产的不言而喻的价值。简单地说，对于一个低价值的系统，一个完全安全的身份验证机制，包括所有的过程，将是矫枉过正，也是错误的安全选择。
显然，对于银行来说，“最佳实践”是必须的，没有办法在道德上违反CWE-257。但是很容易想到低价值系统，这是不值得的（但仍然需要一个简单的密码）。

重要的是要记住，真正的安全专业知识是找到适当的权衡，而不是教条地滔滔不绝地宣扬任何人都可以在线阅读的“最佳实践”。

因此，我建议另一种解决方案：
根据系统的价值，并且仅当系统具有适当的低价值且没有“昂贵”资产（包括身份本身）时，并且存在有效的业务需求，使适当的流程变得不可能（或足够困难/昂贵），并且让客户了解所有注意事项......
然后，简单地允许可逆加密，而不需要跳过特殊的箍。
我只是说根本不打扰加密，因为它的实施非常简单/便宜（即使考虑通过的密钥管理），并且它确实提供了一些保护（超过实施它的成本）。此外，值得研究如何向用户提供原始密码，无论是通过电子邮件，在屏幕上显示等。 由于这里的假设是被盗密码的价值（即使总体上）非常低，因此这些解决方案中的任何一个都可以是有效的。

---

由于在不同的帖子和单独的评论线程中进行了热烈的讨论，实际上是几次热烈的讨论，我将添加一些澄清，并回应这里其他地方提出的一些非常好的观点。

首先，我认为这里的每个人都清楚，允许检索用户的原始密码是不好的做法，通常不是一个好主意。这根本没有争议......
此外，我要强调的是，在许多情况下，不，大多数情况下——这真的是错误的，甚至是肮脏的、令人讨厌的和丑陋的。

然而，问题的关键在于原则，是否有任何情况可能没有必要禁止这样做，如果是，如何以适合情况的最正确方式这样做。

现在，正如@Thomas、@sfussenegger和其他一些人提到的，回答这个问题的唯一正确方法是对任何给定（或假设的）情况进行彻底的风险分析，了解什么是利害攸关的，保护多少，以及还有哪些其他缓解措施来提供这种保护。
不，这不是一个流行语，这是真实安全专业人员的基本、最重要的工具之一。最佳实践在某种程度上是好的（通常作为没有经验和黑客的指南），在那之后，深思熟虑的风险分析接管了。

你知道，这很有趣——我一直认为自己是安全狂热分子之一，不知何故，我站在那些所谓的“安全专家”的对立面......好吧，事实是 - 因为我是一个狂热分子，并且是一个真正的现实生活中的安全专家 - 我不相信在没有最重要的风险分析的情况下滔滔不绝地喋喋不休
“当心安全狂热者，他们迅速应用他们工具带中的所有东西，而不知道他们正在防御的实际问题是什么。更高的安全性并不一定等同于良好的安全性。
风险分析和真正的安全狂热者会指出，基于风险、潜在损失、可能的威胁、补充缓解措施等，进行更明智的、基于价值/风险的权衡。任何“安全专家”如果不能指出合理的风险分析作为其建议的基础，或支持逻辑权衡，而是宁愿在不了解如何进行风险分析的情况下滔滔不绝地滔滔不绝地滔滔不绝地进行教条和 CWE，那么他们都是安全黑客，他们的专业知识不值得他们打印的卫生纸。

事实上，这就是我们得到机场安检的荒谬之处。

但在我们讨论在这种情况下要做出的适当权衡之前，让我们先看看明显的风险（很明显，因为我们没有关于这种情况的所有背景信息，我们都在假设 - 因为问题是可能存在什么假设情况......
让我们假设一个低价值的系统，但又不至于是公共访问——系统所有者希望防止随意冒充，但“高”安全性并不像易用性那么重要。（是的，接受任何精通脚本的孩子都可以入侵该网站的风险是一种合理的权衡......等等，APT现在不是很流行吗......？
举个例子，假设我正在为一个大型家庭聚会安排一个简单的地点，让每个人都可以集思广益，决定我们今年想去哪里露营。我不太担心某个匿名黑客，甚至弗雷德表弟一再建议她回到旺塔纳马纳比基利基湖，就像我担心艾尔玛阿姨在需要时无法登录一样。现在，作为核物理学家的艾尔玛阿姨不太擅长记住密码，甚至根本不擅长使用电脑......所以我想为她消除所有可能的摩擦。同样，我不担心黑客攻击，我只是不想犯错误登录的愚蠢错误——我想知道谁来了，他们想要什么。

无论如何。
那么，如果我们对称加密密码，而不是使用单向哈希，我们在这里的主要风险是什么？

• 冒充用户？不，我已经接受了这种风险，没什么意思。
• 邪恶的管理员？好吧，也许......但同样，我不在乎是否有人可以冒充另一个用户，内部或否......无论如何，恶意管理员无论如何都会获得您的密码 - 如果您的管理员变坏了，无论如何游戏都会结束。
• 提出的另一个问题是，身份实际上是在多个系统之间共享的。啊！这是一个非常有趣的风险，需要仔细研究。
  首先，我要断言，共享的不是实际身份，而是证明或身份验证凭据。好吧，由于共享密码将有效地允许我进入另一个系统（例如，我的银行帐户或 gmail），这实际上是相同的身份，所以它只是语义......但事实并非如此。在此方案中，标识由每个系统单独管理（尽管可能存在第三方 ID 系统，例如 OAuth - 它仍然与此系统中的标识分开 - 稍后会详细介绍）。
  因此，这里的核心风险点是，用户会心甘情愿地将他的（相同）密码输入到几个不同的系统中——现在，我（管理员）或我网站的任何其他黑客都可以访问艾尔玛阿姨的核导弹站点密码。

嗯。

在你看来，这里有什么不对劲的地方吗？

它应该。

让我们从保护核导弹系统不是我的责任这一事实开始，我只是在建造一个 frakkin 家庭郊游网站（为我的家人）。那么是谁的责任呢？呃......核导弹系统怎么样？咄。
其次，如果我想窃取某人的密码（已知在安全站点和不太安全的站点之间反复使用相同密码的人）——我为什么要费心入侵您的网站？还是在为对称加密而苦苦挣扎？Goshdarnitall，我可以建立自己的简单网站，让用户注册以接收他们想要的任何非常重要的新闻......Puffo Presto，我“偷走”了他们的密码。

是的，用户教育总是会回来咬我们，不是吗？
你对此无能为力......即使你要在你的网站上对他们的密码进行哈希处理，并做TSA能想到的所有其他事情，你也会为他们的密码添加保护，而不是一分一毫，如果他们要继续混杂地将他们的密码粘贴到他们碰到的每个网站。甚至不要费心去尝试。

换句话说，你不拥有他们的密码，所以不要再试图像你一样行事了。

所以，我亲爱的安全专家，正如一位老太太曾经问温迪的一样，“风险在哪里？

在回答上述一些问题时，还有几点：

• CWE不是法律、法规，甚至不是标准。它是常见弱点的集合，即“最佳实践”的反面。
• 共享身份的问题是一个实际的问题，但被这里的反对者误解（或歪曲）。这是一个共享身份本身的问题（！），而不是破解低价值系统上的密码。如果您在低价值和高价值系统之间共享密码，那么问题已经存在！
• 顺便说一句，前一点实际上反对对这些低价值系统和高价值银行系统使用 OAuth 等。
• 我知道这只是一个例子，但（可悲的是）联邦调查局的系统并不是最安全的。不太像你猫的博客的服务器，但它们也没有超过一些更安全的银行。
• 加密密钥的拆分知识或双重控制不仅发生在军队中，事实上，PCI-DSS现在基本上要求所有商家这样做，所以它不再那么遥远了（如果价值证明它是合理的）。
• 对于那些抱怨这些问题让开发人员职业看起来如此糟糕的人：正是这样的答案让安全行业看起来更糟。同样，以业务为中心的风险分析是必需的，否则你会让自己变得毫无用处。除了错了。
• 我想这就是为什么只让一个普通的开发人员把更多的安全责任放在他身上不是一个好主意，而没有训练他以不同的方式思考，并寻找正确的权衡。没有冒犯，对在座的你们这些人来说，我完全赞成——但更多的培训是有序的。

呼。多么长的帖子......
但要回答你最初的问题，@Shane：

• 向客户解释正确的做事方式。
• 如果他仍然坚持，再解释一些，坚持，争论。如果需要，发脾气。
• 向他解释商业风险。细节很好，数字更好，现场演示通常是最好的。
• 如果他仍然坚持，并提出有效的商业理由 - 是时候让你做出判断了：
  这个网站的价值低到没有价值吗？这真的是一个有效的商业案例吗？这对你来说足够好吗？您是否没有可以考虑的其他风险，这些风险会超过有效的业务原因？（当然，客户端不是恶意网站，但那是呃）。
  如果是这样，请继续前进。不值得付出努力、摩擦和丢失使用（在这种假设情况下）来实施必要的过程。任何其他决定（同样，在这种情况下）都是一个糟糕的权衡。

因此，底线和实际答案 - 使用简单的对称算法对其进行加密，使用强 ACL 保护加密密钥，最好是 DPAPI 等，将其记录下来并让客户（足够资深的人来做出决定）签字。

您不能以合乎道德的方式存储密码以供以后进行明文检索。就这么简单。即使是 Jon Skeet 也无法从道德上存储密码以供以后进行明文检索。如果您的用户可以以某种方式以纯文本形式检索密码，那么在您的代码中发现安全漏洞的黑客也可能如此。这不仅仅是一个用户的密码被泄露，而是所有用户的密码都被泄露。

如果您的客户对此有疑问，请告诉他们存储可恢复的密码是违法的。无论如何，在英国，《1998年数据保护法》（特别是附表1，第二部分，第9段）要求数据控制者使用适当的技术措施来保护个人数据的安全，其中包括，如果数据被泄露可能造成的损害 - 这对于在网站之间共享密码的用户来说可能是相当大的。如果他们仍然难以理解这是一个问题的事实，请向他们指出一些真实世界的例子，比如这个例子。

允许用户恢复登录的最简单方法是通过电子邮件向他们发送一个一次性链接，该链接会自动登录并直接将他们带到一个页面，他们可以在其中选择新密码。创建一个原型并向他们展示它的实际效果。

以下是我写的几篇关于这个主题的博客文章：

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

更新：我们现在开始看到针对未能正确保护用户密码的公司的诉讼和起诉。示例：LinkedIn 被打了 500 万美元的集体诉讼;索尼因PlayStation数据黑客攻击被罚款25万英镑。如果我没记错的话，LinkedIn实际上正在加密其用户的密码，但它使用的加密太弱而无法有效。

在注册时通过电子邮件发送明文密码，然后再对其进行加密和丢失怎么办？我见过很多网站都这样做，从用户的电子邮件中获取该密码比将其留在您的服务器/组合上更安全。

用户是否真的需要恢复（例如被告知）他们忘记的密码是什么，或者他们只是需要能够进入系统？如果他们真正想要的是登录密码，为什么不制定一个例程，简单地将旧密码（无论它是什么）更改为支持人员可以提供给丢失密码的人的新密码？

我曾经使用过完全做到这一点的系统。支持人员无法知道当前密码是什么，但可以将其重置为新值。当然，所有这些重置都应该记录在某个地方，好的做法是向用户发送一封电子邮件，告诉他密码已被重置。

另一种可能性是同时使用两个密码来允许访问一个帐户。一个是用户管理的“普通”密码，另一个是骨架/主密钥，只有支持人员知道，并且对所有用户都是相同的。这样，当用户遇到问题时，支持人员可以使用主密钥登录帐户，并帮助用户将其密码更改为任何密码。毋庸置疑，系统也应该记录所有使用主密钥的登录。作为一项额外措施，每当使用主密钥时，您也可以验证支持人员的凭据。

-编辑- 针对有关没有主密钥的评论：我同意这很糟糕，就像我认为允许用户以外的任何人访问用户帐户是不好的一样。如果你看一下这个问题，整个前提是客户强制要求一个高度受损的安全环境。

主密钥不必像最初看起来那么糟糕。我曾经在一家国防工厂工作，他们认为大型计算机操作员在某些情况下需要拥有“特殊访问权限”。他们只需将特殊密码放入密封的信封中，然后将其贴在操作员的办公桌上。要使用密码（操作员不知道），他必须打开信封。每次换班时，值班主管的一项工作就是查看信封是否已打开，如果是，请立即更改密码（由另一个部门更改），并将新密码放入新信封中，然后重新开始该过程。操作员将被问及他为什么要打开它，并将事件记录在案。

虽然这不是我会设计的程序，但它确实奏效并提供了出色的问责制。一切都被记录和审查，而且所有操作员都有国防部的秘密许可，我们从来没有发生过任何滥用行为。

由于审查和监督，所有经营者都知道，如果他们滥用打开信封的特权，他们将立即被解雇，并可能受到刑事起诉。

所以我想真正的答案是，如果一个人想把事情做对，就要雇用他们可以信任的人，进行背景调查，并实行适当的管理监督和问责制。

但话又说回来，如果这个可怜的家伙的客户有良好的管理，他们一开始就不会要求这样一个安全解决方案，现在他们会吗？

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

将密码的不可检索加密存储在站点的数据库中（我们称之为“pass-a”），就像普通人所做的那样:)每个新用户（或密码更改）
时，在远程数据库中存储密码的普通副本。使用服务器的 ID、用户的 ID 和“pass-a”作为此密码的组合键。您甚至可以对密码使用双向加密，以便在晚上睡得更好。

现在，为了让某人同时获得密码及其上下文（站点 ID + 用户 ID + “pass-a”），他必须：

1. 破解网站的数据库以获得（“pass-a”，用户 ID）对或对。
2. 从某个配置文件中获取网站的 ID
3. 查找并入侵远程密码数据库。

您可以控制密码检索服务的可访问性（仅将其公开为受保护的 Web 服务，每天只允许一定数量的密码检索，手动进行等），甚至可以为此“特殊安全安排”收取额外费用。
密码检索数据库服务器非常隐蔽，因为它没有提供很多功能，并且可以更好地保护（您可以严格定制权限、流程和服务）。

总而言之，你让黑客的工作更加困难。任何一台服务器上出现安全漏洞的可能性仍然相同，但有意义的数据（帐户和密码的匹配）将很难收集。

看完这部分：

在下面的注释中，我指出了这一点 主要面向 老年人、智障人士或非常 年轻会让人感到困惑 当他们被要求执行 安全密码恢复例程。 虽然我们可能会发现它很简单和 在这些情况下，一些用户需要 任何一个拥有的额外帮助 服务技术人员帮助他们进入 系统或通过电子邮件发送/显示 直接给他们。

在这样的系统中，损耗率 从这些人口统计数据中可能会步履蹒跚 应用程序（如果用户不是） 鉴于这种级别的访问协助， 所以请回答这样的设置 介意。

我想知道这些要求中是否有任何一个要求需要可检索的密码系统。例如： 梅布尔阿姨打来电话说：“你的互联网程序不起作用，我不知道我的密码”。“好的，”客服无人机说，“让我检查一些细节，然后我会给你一个新密码。当您下次登录时，它会询问您是要保留该密码还是将其更改为您更容易记住的密码。

然后，系统设置为知道何时发生密码重置，并显示“您是要保留新密码还是选择新密码”消息。

对于不太懂 PC 的人来说，这比被告知他们的旧密码更糟糕吗？虽然客户服务人员可以恶作剧，但数据库本身在被破坏时要安全得多。

评论我的建议有什么不好的地方，我会建议一个真正满足你最初想要的解决方案。

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

• 用户是否从通过电子邮件发送密码中受益？不。他们从一次性密码重置链接中获得更多好处，这有望使他们能够选择他们会记住的密码。
• 用户是否受益于在屏幕上显示其密码？不，原因与上述相同;他们应该选择一个新密码。
• 让支持人员向用户说出密码对用户是否有益？不;同样，如果支持人员认为用户对其密码的请求已正确通过身份验证，则获得新密码并有机会更改密码更有利于用户。此外，电话支持比自动密码重置更昂贵，因此该公司也没有受益。

似乎唯一可以从可恢复密码中受益的是那些具有恶意意图的人或需要第三方密码交换的不良 API 的支持者（请不要使用上述 API！也许您可以通过如实向您的客户说明公司通过存储可恢复的密码而获得任何利益，而只获得责任来赢得您的论点。

阅读这些类型的请求的字里行间，您会发现您的客户可能根本不了解甚至根本不关心密码的管理方式。他们真正想要的是一个对用户来说不那么难的身份验证系统。因此，除了告诉他们他们实际上不想要可恢复的密码之外，您还应该为他们提供使身份验证过程不那么痛苦的方法，尤其是在您不需要银行等高安全级别的情况下：

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

但是，如果您出于某种原因（请告诉我们原因）真的、真的、真的需要能够拥有可恢复的密码，您可以通过为用户提供非基于密码的身份验证系统来保护用户免受潜在损害他们的其他在线帐户。因为人们已经熟悉用户名/密码系统，并且它们是一种经过充分锻炼的解决方案，所以这将是最后的手段，但肯定有很多创造性的密码替代方案：

• 让用户选择数字引脚，最好不要是 4 位数字，最好仅在暴力破解尝试受到保护的情况下才选择。
• 让用户选择一个只有他们知道答案的问题，永远不会改变，他们会永远记住，而且他们不介意其他人发现。
• 让用户输入用户名，然后绘制一个易于记忆的形状，并具有足够的排列以防止猜测（请参阅这张漂亮的照片，了解 G1 如何解锁手机）。
• 对于儿童网站，您可以根据用户名（有点像标识符）自动生成一个模糊的生物，并要求用户给该生物一个秘密名称。然后，系统会提示他们输入生物的秘密名称进行登录。

保护凭据不是二进制操作：安全/不安全。安全性是关于风险评估的，并且是连续衡量的。安全狂热者讨厌这样想，但丑陋的事实是，没有什么是完全安全的。具有严格密码要求的哈希密码、DNA 样本和视网膜扫描更安全，但会以开发和用户体验为代价。明文密码的安全性要低得多，但实施起来成本更低（但应避免使用）。归根结底，它归结为对违规行为的成本/收益分析。您可以根据所保护数据的值及其时间值来实现安全性。

某人的密码被泄露到野外的成本是多少？在给定系统中模拟的成本是多少？对于联邦调查局的计算机来说，成本可能是巨大的。对于 Bob 的一次性五页网站来说，成本可以忽略不计。专业人员为他们的客户提供选择，并在安全性方面列出任何实施的优势和风险。如果客户要求由于不遵守行业标准而可能使他们面临风险的东西，则情况会加倍。如果客户特别要求双向加密，我会确保你记录你的反对意见，但这不应该阻止你以你所知道的最佳方式实施。归根结底，这是客户的钱。是的，你应该推动使用单向哈希，但说这绝对是唯一的选择，其他任何事情都是不道德的，这完全是无稽之谈。

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

据我所知，没有任何法律（英国的《数据保护法》）明确规定密码必须使用单向哈希进行存储。这些法律中的任何一项的唯一要求只是采取合理的安全措施。如果对数据库的访问受到限制，即使是纯文本密码也可以合法地受到这种限制。

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

在这个问题上采取另一种方法或角度怎么样？询问为什么密码必须是明文的：如果这样用户可以检索密码，那么严格来说，您实际上不需要检索他们设置的密码（反正他们不记得密码是什么），您需要能够给他们一个可以使用的密码。

想一想：如果用户需要找回密码，那是因为他们忘记了密码。在这种情况下，新密码与旧密码一样好。但是，目前使用的常见密码重置机制的缺点之一是，重置操作中生成的密码通常是一堆随机字符，因此用户很难简单地正确输入，除非他们复制粘贴。对于不太精明的计算机用户来说，这可能是一个问题。

解决该问题的一种方法是提供自动生成的密码，这些密码或多或少是自然语言文本。虽然自然语言字符串可能没有相同长度的随机字符字符串所具有的熵，但没有任何内容表明您自动生成的密码只需要有 8 个（或 10 个或 12 个）字符。通过将几个随机单词串在一起来获取高熵自动生成的密码（在它们之间留出一个空格，以便任何可以阅读的人仍然可以识别和输入它们）。与10个随机字符相比，6个不同长度的随机单词可能更容易正确和自信地输入，并且它们也可以具有更高的熵。例如，从大写、小写、数字和 10 个标点符号（总共 72 个有效符号）中随机抽取的 10 个字符密码的熵为 61.7 位。使用一个包含 7776 个单词的字典（如 Diceware 使用），可以随机选择用于六个单词的密码短语，密码短语的熵为 77.4 位。有关更多信息，请参阅 Diceware 常见问题解答。

• 一个熵约为 77 位的密码：“承认散文耀斑表敏锐的天赋”

• 熵约为 74 位的密码：“K：&$R^tt~qkD”

我知道我更喜欢输入短语，并且使用复制粘贴，该短语的易用性也不亚于密码，因此不会丢失。当然，如果您的网站（或任何受保护的资产）不需要 77 位熵来自动生成的密码短语，请生成更少的单词（我相信您的用户会喜欢）。

我理解这样的论点，即有些受密码保护的资产确实没有很高的价值，因此密码泄露可能不是世界末日。例如，我可能不会在乎我在各种网站上使用的 80% 的密码是否被泄露：所有可能发生的事情都是有人以我的名义发送垃圾邮件或发帖一段时间。那不是很好，但他们不会闯入我的银行账户。但是，鉴于许多人在他们的网络论坛网站上使用与银行账户（可能还有国家安全数据库）相同的密码，我认为最好将那些“低价值”密码处理为不可恢复。

如果您不能拒绝存储可恢复密码的要求，那么将其作为您的反驳论点怎么样？

我们可以正确地散列密码并为用户建立重置机制，也可以从系统中删除所有个人身份信息。您可以使用电子邮件地址来设置用户首选项，但仅此而已。使用 cookie 自动提取未来访问的偏好，并在合理的时间段后丢弃数据。

密码策略经常忽略的一个选项是是否真的需要密码。如果您的密码策略唯一做的就是引起客户服务电话，也许您可以摆脱它。

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

我有同样的问题。同样，我总是认为有人入侵了我的系统，这不是“如果”的问题，而是“何时”的问题。

因此，当我必须做一个需要存储可恢复机密信息（如信用卡或密码）的网站时，我所做的是：

• 加密方式：openssl_encrypt（string $data ， string $method ， string $password）
  • PHP手册。
• 数据参数：
  • 敏感信息（例如用户密码）
  • 必要时进行序列化，例如，如果信息是多个敏感信息等数据数组
• 密码参数：使用只有用户知道的信息，例如：
  • 用户车牌
  • 社会安全号码
  • 用户电话号码
  • 用户母名称
  • 注册时通过电子邮件和/或短信发送的随机字符串
• 方法参数：
  • 选择一种密码方法，例如“AES-256-CBC”
• 切勿将“password”参数中使用的信息存储在数据库（或系统中的任何地方）

当有必要检索这些数据时，只需使用“openssl_decrypt（）”函数并向用户询问答案。例如：“要接收您的密码，请回答以下问题：您的手机号码是什么？

PS 1：切勿将存储在数据库中的数据用作密码。如果需要存储用户手机号码，则切勿使用此信息对数据进行编码。始终使用只有用户知道或非亲戚很难知道的信息。

PS 2：对于信用卡信息，例如“一键购买”，我所做的就是使用登录密码。此密码在数据库（sha1、md5 等）中进行哈希处理，但在登录时，我将纯文本密码存储在会话中或非持久性（即在内存中）安全 cookie 中。这个普通密码永远不会留在数据库中，事实上它总是留在内存中，在部分末尾被销毁。当用户点击“一键购买”按钮时，系统将使用此密码。如果用户使用 facebook、twitter 等服务登录，那么我会在购买时再次提示密码（好吧，这不是完全“点击”），或者然后使用用户用于登录的服务的一些数据（如 facebook id）。

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

因此，步骤将是：

1. 用户在您的网站上注册（当然是通过SSL），但尚未设置密码。自动登录或提供临时密码。
2. 您提出存储其公共 PGP 密钥以供将来检索密码。
3. 他们上传其公共 PGP 密钥。
4. 您要求他们设置新密码。
5. 他们提交密码。
6. 您可以使用可用的最佳密码哈希算法（例如 bcrypt）对密码进行哈希处理。在验证下次登录时使用此选项。
7. 您可以使用公钥加密密码，并将其单独存储。

如果用户随后要求输入密码，则使用加密（未哈希处理）密码进行响应。如果用户不希望将来能够检索其密码（他们只能将其重置为服务生成的密码），则可以跳过步骤 3 和 7。

刚刚遇到了这个有趣而激烈的讨论。 然而，最令我惊讶的是，对以下基本问题的关注如此之少：

• 问题1.用户坚持访问纯文本存储密码的实际原因是什么？为什么它有如此大的价值？

用户是年长还是年轻的信息并不能真正回答这个问题。但是，如果不正确理解客户的关注点，如何做出业务决策呢？

现在为什么这很重要？ 因为如果客户要求的真正原因是系统难以使用，那么解决确切原因可能会解决实际问题？

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

我看到的另一个问题问：

• 问题2.如果用户一开始就不记得密码，为什么旧密码很重要？

这是可能的答案。 如果你有一只叫“miaumiau”的猫，并使用她的名字作为密码，但忘记了你，你更愿意被提醒它是什么，还是更确切地说，被发送类似“#zy*RW（ew”）的东西？

另一个可能的原因是用户认为想出一个新密码是一项艰巨的工作！因此，将旧密码寄回会给人一种错觉，可以再次将她从痛苦的工作中解救出来。

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

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

如果我登录新闻网站阅读报纸，我想输入 1111 作为密码并通过!!

我知道这是不安全的，但我在乎有人访问我的“帐户”吗？是的，他也可以阅读新闻！

该网站是否存储我的“私人”信息？ 我今天读到的新闻？ 然后是网站的问题，不是我的问题！ 网站是否向经过身份验证的用户显示私人信息？ 那就不要先展示它了！

这只是为了展示用户对问题的态度。

总而言之，我不认为这是如何“安全”存储纯文本密码的问题（我们知道这是不可能的），而是如何解决客户的实际问题。

根据我对这个主题的了解，我相信如果你正在建立一个带有登录/密码的网站，那么你甚至不应该在你的服务器上看到明文密码。在密码离开客户端之前，应该对密码进行哈希处理，并且可能对其进行加盐处理。

如果您从未看到明文密码，则不会出现检索问题。

此外，我（从网络上）收集到（据称）某些算法（例如 MD5）不再被认为是安全的。我自己无法判断，但这是需要考虑的事情。

您可能没有考虑过的另一个选项是允许通过电子邮件执行操作。这有点麻烦，但我为一个客户端实现了这一点，该客户端需要用户“在系统外部”查看（只读）系统的某些部分。例如：

1. 用户注册后，即可获得完全访问权限（如常规 网站）。注册必须包括电子邮件。
2. 如果需要数据或操作，而用户不需要 记住他们的密码，他们仍然可以通过以下方式执行操作 单击一个特殊的“向我发送电子邮件以获得许可”按钮，就在常规“提交”按钮旁边。
3. 然后，该请求将发送到带有超链接的电子邮件，询问他们是否希望执行该操作。这类似于密码重置电子邮件链接，但它不是重置密码，而是执行一次性操作。
4. 然后，用户单击“是”，并确认应显示数据，或应执行操作，显示数据等。

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

此解决方案的一个转折点是将操作请求发送给第三方受信任的管理员。这在老年人、智障人士、非常年轻或有其他困惑的用户的情况下效果最好。当然，这需要一个受信任的管理员来支持这些人的行动。

像往常一样对用户的密码进行加盐和哈希处理。登录用户时，既要允许用户的密码（加盐/散列后），也要允许用户实际输入的内容匹配。

这允许用户输入他们的秘密密码，但也允许他们输入密码的加盐/哈希版本，这是某人从数据库中读取的内容。

基本上，使加盐/散列的密码也成为“纯文本”密码。