随着我继续构建越来越多的网站和Web应用程序，我经常被要求以一种方式存储用户的密码，如果/当用户遇到问题时可以检索它们（要么通过电子邮件发送忘记的密码链接，请通过当我能够对抗这种做法时，我会做很多“额外”编程，以便在不存储实际密码的情况下进行密码重置和管理协助 .
当我无法抗争（或无法获胜）时，我总是以某种方式对密码进行编码，以至于它至少不会以明文形式存储在数据库中 - 尽管我知道如果我的数据库被黑客攻击罪魁祸首破解密码并不需要太多，所以这让我感到不舒服 .
在一个完美的世界里，人们经常更新密码，而不是在许多不同的网站上复制密码 - 不幸的是，我知道很多人拥有相同的工作/家庭/电子邮件/银行密码，甚至在需要帮助时自由地给我 . 如果我的数据库安全程序由于某种原因失败，我不想成为他们的财务危机负责人 .
在道德和道德上，我觉得有责任保护一些用户的生活，即使他们以较少的尊重对待他们 . 我确信有许多途径可以用来腌制哈希和不同的编码选项，但是当你必须存储它们时，是否有一个“最佳实践”？在几乎所有情况下，我都使用PHP和MySQL，如果这对我应该处理细节的方式有任何不同 .
Additional Information for Bounty
我想澄清一点，我知道这不是你想要做的事情，在大多数情况下拒绝这样做是最好的 . 但是，我并不是在寻找关于采用这种方法的优点的讲座我正在寻找采取这种方法时采取的最佳步骤 .
在下面的一个注释中，我指出，当人们被要求执行安全的密码恢复程序时，主要针对老年人，精神挑战者或非常年轻人的网站可能会让人感到困惑 . 虽然在这些情况下我们可能会发现它简单而平凡，但有些用户需要额外的帮助，要么让服务技术人员帮助他们进入系统，要么将其直接通过电子邮件发送/显示给他们 .
在这样的系统中，如果用户没有获得这种级别的访问协助，那么来自这些人口统计数据的流失率可能会阻碍应用程序，因此请记住这样的设置 .
Thanks to Everyone
这是一个有趣的问题，有很多争论，我很喜欢它 . 最后，我选择了一个保留密码安全性的答案（我不必保留纯文本或可恢复的密码），但也使我指定的用户群可以登录到系统而没有我从中发现的主要缺点正常的密码恢复 .
一如既往有大约5个答案，我希望由于不同的原因标记为正确，但我必须选择最好的答案 - 所有其余的都得到1.谢谢大家！
此外，感谢Stack社区中的每个人都投票赞成这个问题和/或将其标记为收藏 . 我以100票赞成票作为赞美，并希望这次讨论能够帮助其他与我有同样关切的人 .
26 回答
中途宿舍怎么样？
使用强加密存储密码，不要启用重置 .
允许发送一次性密码（必须在第一次登录时立即更改），而不是重置密码 . 然后让用户更改为他们想要的任何密码（前一个，如果他们选择） .
您可以将其“出售”为重置密码的安全机制 .
正常地对用户密码进行加盐和散列 . 在登录用户时，允许用户的密码（在salting / hashing之后），但也允许用户输入的内容也匹配 .
这允许用户输入他们的密码，但也允许他们输入他们的密码的salted / hashed版本，这是有人从数据库中读取的 .
基本上，使salted / hashed密码也是“纯文本”密码 .
如何在注册时通过电子邮件发送明文密码，然后再加密并丢失？我已经看到很多网站都这么做了，从用户的电子邮件中获取密码比将它留在服务器/ comp上更安全 .
想象一下，有人委托建造了一座大楼 - 比如一个酒吧 - 并且会发生以下对话：
Architect: 对于这样大小和容量的建筑物，这里和这里都需要消防通道 .
Client: 不，那个's too complicated and expensive to maintain, I don't想要任何侧门或后门 .
Architect: 先生，消防通道不是可选的，根据城市的防火规范，它们是必需的 .
Client: 我不付钱给你辩护 . 做我所问的 .
然后，建筑师会问如何在没有火灾的情况下道德地建造这座建筑退出？
在建筑和工程行业，谈话最有可能像这样结束：
Architect: 这座建筑无法在没有消防通道的情况下建造 . 你可以去任何其他有执照的专业人士，他会告诉你同样的事情 . 现在我要走了;当你准备合作时，给我回电话 .
计算机编程可能不是一个许可的专业，但人们似乎常常想知道为什么我们的专业不会得到与民用或机械工程师相同的尊重 - 好吧，不要再看了 . 那些职业，当交给垃圾（或完全危险）的要求时，将简单地拒绝 . 他们知道这不是一个借口说，"well, I did my best, but he insisted, and I've gotta do what he says."他们可能因为这个借口而失去执照 .
我不知道您或您的客户是否属于任何上市公司，但以任何可恢复的形式存储密码会导致您失败几种不同类型的安全审核 . 问题不在于有些访问您的数据库以恢复密码的人有多困难 . The vast majority of security threats are internal. 您需要防范的是一些心怀不满的员工走出所有密码并将其出售给出价最高者 . 使用非对称加密并将私钥存储在单独的数据库中绝对不能阻止这种情况;总是会有人访问私人数据库，这是一个严重的安全风险 .
There is no ethical or responsible way to store passwords in a recoverable form. Period.
不要放弃 . 您可以用来说服客户的武器是不可否认的 . 如果您可以通过任何机制重建用户密码，您已经为其客户提供了合法的不可否认机制，并且他们可以拒绝任何依赖于该密码的交易，因为供应商无法证明他们没有对案件进行过工作 . 这将达到数亿美元 . 不是你想要出错的东西 .
刚刚遇到了这个有趣而激烈的讨论 . 最令我惊讶的是，对以下基本问题的关注很少：
用户年长或年轻的信息并不能真正回答这个问题 . 但是，如果没有正确理解客户的关注，如何做出业务决策？
现在为什么重要？因为如果客户要求的真正原因是难以使用的系统，那么解决确切原因可能会解决实际问题吗？
由于我没有这些信息而且无法与这些客户交谈，我只能猜测：这是关于可用性，见上文 .
我见过的另一个问题是：
这是可能的答案 . 如果你有一个名为“miaumiau”的猫，并且使用她的名字作为密码，但忘了你做了，你是否愿意提醒它是什么，或者更确切地说是发送了类似“＃zy * RW（ew”？
另一个可能的原因是用户认为提出新密码是一项艰苦的工作！因此，将旧密码发送回去会产生一种幻想，即让她再次从痛苦的工作中解脱出来 .
我只是想了解原因 . 但无论原因是什么，这都是不必解决原因的原因 .
作为用户，我希望事情简单！我不想努力！
如果我登录新闻网站阅读报纸，我想输入1111作为密码并通过！
我知道这是不安全的，但我关心有人访问我的“帐户”？是的，他也可以阅读新闻！
该网站是否存储我的“私人”信息？我今天读的新闻？然后这是网站的问题，而不是我的！该网站是否向经过身份验证的用户显示私人信息？然后不要把它显示在第一位！
这只是为了证明用户对问题的态度 .
总而言之，我不认为如何“安全地”存储纯文本密码（我们知道这是不可能的），而是如何解决客户的实际问题 .
您可以使用公钥加密密码盐 . 对于登录，只需检查存储的值是否等于从用户输入salt计算的值 . 如果有时间，当需要以明文恢复密码时，您可以使用私钥手动或半自动解密 . 私钥可以存储在别处，并且可以另外对称加密（这将需要人工交互来解密密码） .
我认为这实际上与Windows Recovery Agent的工作方式类似 .
密码以加密方式存储
人们可以登录而无需解密到明文
密码可以恢复为纯文本，但只能使用私钥，可以存储在系统外部（如果您愿意，可以存储在银行保险箱中） .
在独立服务器上打开数据库，并为需要此功能的每个Web服务器提供加密的远程连接 .
它不必是关系数据库，它可以是具有FTP访问权限的文件系统，使用文件夹和文件而不是表和行 .
如果可以，请为Web服务器提供只写权限 .
将不可检索的密码加密存储在网站's DB (let'中称之为"pass-a"）就像普通人一样:)
在每个新用户（或密码更改）上，在远程数据库中存储密码的纯文本 . 使用服务器's id, the user'的ID和"pass-a"作为此密码的复合键 . 您甚至可以使用密码双向加密来在晚上睡得更好 .
现在，为了让某人同时获得密码及其上下文（网站ID用户ID“pass-a”），他必须：
破解网站的数据库以获得（"pass-a"，用户ID）对或对 .
从中获取网站的ID一些配置文件
查找并入侵远程密码DB .
您可以控制密码检索服务的可访问性（仅将其公开为安全的Web服务，每天仅允许一定数量的密码检索，手动执行等），甚至为此"special security arrangement"收取额外费用 .
密码检索DB服务器非常隐蔽，因为它不能提供很多功能，并且可以更好地保护（您可以紧密地定制权限，流程和服务） .
总而言之，你让黑客的工作更加努力 . 任何单一服务器上发生安全漏洞的可能性仍然相同，但有意义的数据（帐户和密码的匹配）将难以组装 .
如果你不能拒绝存储可恢复密码的要求，那么作为你的反驳论据如何 .
我们可以正确地散列密码并为用户构建重置机制，或者我们可以从系统中删除所有个人身份信息 . 您可以使用电子邮件地址来设置用户首选项，但这是关于它的 . 使用cookie自动提取未来访问的偏好，并在合理的时间段后丢弃数据 .
密码策略经常忽略的一个选项是密码是否真的需要 . 如果你的密码政策唯一能做的就是引起客户服务电话，也许你可以摆脱它 .
看完这部分后：
我'm left wondering if any of these requirements mandate a retrievable password system. For instance: Aunt Mabel calls up and says 257941 . 257942 says the customer service drone "let me check a few details and then I' ll give you a new password . 当您下次登录时，它会询问您是否要保留该密码或将其更改为您可以更容易记住的密码 . “
然后系统设置为知道密码重置何时发生并显示“您想保留新密码还是选择新密码”消息 .
与被告知旧密码相比，对于识字能力较差的人来说，这会更糟糕吗？虽然客户服务人员可以起到恶作剧的作用，但数据库本身在被破坏时更加安全 .
评论我的建议有什么不好，我会建议一个实际上做你最初想要的解决方案 .
我有同样的问题 . 同样地，我总是认为有人破解了我的系统，这不是“如果”而是“何时”的问题 .
所以，当我必须 Build 一个需要存储可恢复的机密信息的网站时，比如信用卡或密码，我做的是：
加密： openssl_encrypt （字符串$ data，字符串$ method，字符串$ password）
PHP manual .
data arg ：
敏感信息（例如用户密码）
如有必要，
序列化，例如如果信息是多个敏感信息之类的数据数组
password arg ：使用只有用户知道的信息：
用户牌照
社会安全号码
用户电话号码
用户母亲姓名
在注册时通过电子邮件和/或短信发送的随机字符串
method arg ：
选择一种密码方法，如"aes-256-cbc"
NEVER 将"password"参数中使用的信息存储在数据库（或系统中的任何位置）
必要时，只需使用"openssl_decrypt()"函数来检索此数据并询问用户答案 . 例如："To receive your password answer the question: What's your cellphone number?"
PS 1：永远不要将数据存储在数据库中用作密码 . 如果您需要存储用户手机号码，请不要使用此信息对数据进行编码 . 始终使用只有用户知道的信息，或者非亲属知道的信息 .
PS 2：对于信用卡信息，如"one click buying"，我所做的就是使用登录密码 . 此密码在数据库（sha1，md5等）中进行哈希处理，但在登录时我将明文密码存储在会话中或非持久（即内存）安全cookie中 . 这个普通密码永远不会留在数据库中，实际上's always stay in memory, destroyed at end of section. When the user click at 258006 button the system use this password. If the user was logged in with a service like facebook, twitter, etc, then I prompt the password again at buying time (ok, it'不是完全"on click"）或者然后使用用户用来登录的服务的一些数据（比如facebook id） .
在那里，我想添加一些好处 . 到目前为止，我还没有看到一个合法的好处，就是在系统上存储了可恢复的密码 . 考虑一下：
用户是否可以通过电子邮件将密码发送给用户？不会 . 他们从一次性密码重置链接中获得更多好处，这有望让他们选择一个他们会记住的密码 .
用户是否可以在屏幕上显示密码？不，出于与上述相同的原因;他们应该选择一个新密码 .
用户是否可以让支持人员向用户说出密码？没有;再次，如果支持人员认为用户更有利于用户's benefit to be given a new password and the opportunity to change it. Plus, phone support is more costly than automated password resets, so the company also doesn' t .
似乎唯一可以从可恢复密码中受益的是那些具有恶意意图的人或者需要第三方密码交换的不良API的支持者（请不要使用所述API！） . 也许你可以通过真实地向你的客户说明 the company gains no benefits and only liabilities by storing recoverable passwords 来赢得你的论点 .
在这些类型的请求之间进行读取，您甚至不了解密码的管理方式 . 他们真正想要的是一个实际上不需要可恢复密码的身份验证系统，您应该为他们提供一些方法来减少身份验证过程，特别是如果您不需要银行的严重安全级别：
允许用户使用其电子邮件地址作为其用户名 . 我见过无数用户忘记用户名的情况，但很少忘记他们的电子邮件地址 .
提供OpenID并让第三方支付用户健忘的费用 .
减轻密码限制 . 当一些网站没有忘记时，我已经非常恼火了 .
不要使密码过期 .
允许用户重复使用旧密码 .
允许用户选择自己的密码重置问题 .
但是，如果您出于某种原因（并且请告诉我们原因）真的，确实需要能够拥有可恢复的密码，您可以通过向用户提供非密码来保护用户免受其他在线帐户的侵害 - 基于认证的系统 . 因为人们已经熟悉用户名/密码系统并且它们是一个运行良好的解决方案，这将是最后的手段，但肯定有很多创造性的替代密码：
让用户选择一个数字引脚，最好不是4位数，最好只有在强力尝试受到保护的情况下 .
让用户选择一个简短回答的问题，只有他们知道答案，永远不会改变，他们会永远记住，他们不介意其他人发现 .
让用户输入一个用户名，然后绘制一个易于记忆的形状，并有足够的排列以防止猜测（参见this nifty photo G1如何解锁手机） .
给孩子's web site, you could auto-generate a fuzzy creature based on the user name (sort of like an identicon) and ask the user to give the creature a secret name. They can then be prompted to enter the creature'登录的秘密名称 .
您无法合乎道德地存储密码以便以后进行明文检索 . 它不仅仅是一个用户的密码遭到入侵，而是 all of them.
如果您的客户遇到问题，请告诉他们存储密码是可以接受的，这是违法的 . 无论如何，在英国，“1998年数据保护法”（特别是附表1，第II部分，第9段）要求数据管理员使用适当的技术措施来保护个人数据的安全，同时考虑到如果数据受到损害可能造成的伤害 - 对于在站点之间共享密码的用户而言，这可能是相当大的 . 如果他们仍然无法解决这个问题，请将它们指向一些真实的例子，例如this one .
允许用户恢复登录的最简单方法是通过电子邮件向他们发送自动登录的一次性链接，并将其直接带到可以选择新密码的页面 . 创建一个原型并将其展示给他们 .
这是我写的关于这个主题的几篇博文：
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/
Update: 我们现在开始看到针对未能正确保护用户密码的公司的诉讼和起诉 . 示例：LinkedIn slapped with $5 million class action lawsuit; Sony fined £250,000 over PlayStation data hack . 如果我没记错的话，LinkedIn实际上正在加密其用户的密码，但它使用的加密太弱而无法生效 .
保护凭证不是二进制操作：安全/不安全 . 安全是关于风险评估的，并且是连续的 . 安全狂热分子讨厌这样思考，但丑陋的事实是没有什么是完全安全的 . 具有严格密码要求的哈希密码，DNA样本和视网膜扫描更安全，但代价是开发和用户体验 . 明文密码的安全性要低得多，但实施起来要便宜（但应该避免） . 在一天结束时，它归结为对违规行为的成本/收益分析 . 您可以根据受保护数据的值及其时间值来实现安全性 .
某人的密码进入野外的成本是多少？在给定系统中模仿的成本是多少？对FBI计算机来说，成本可能是巨大的 . 对Bob的一次性五页网站来说，成本可以忽略不计 . 专业人员为其客户提供选择，并且在安全性方面，列出了任何实施的优势和风险 . 如果客户请求可以放置的东西，这是双倍的由于未能遵守行业标准，他们处于危险之中 . 如果客户特别要求双向加密，我会确保您记录您的异议，但这不应该阻止您以您知道的最佳方式实施 . 在一天结束时，这是客户的钱 . 是的，你应该推动使用单向哈希，但要说这绝对是唯一的选择而其他任何不道德的行为都是完全无稽之谈 .
如果您使用双向加密存储密码，则安全性都归结为密钥管理 . Windows提供了一些机制来限制对管理帐户和密码的证书私钥的访问 . 如果您在其他平台上托管，则需要查看可用的选项 . 正如其他人所建议的那样，您可以使用非对称加密 .
我没有法律（英国的数据保护法案），我知道具体说明密码必须使用单向哈希存储 . 任何这些法律中唯一的要求就是采取了 reasonable 步骤以确保安全 . 如果限制访问数据库，即使是明文密码也可以在这种限制下合法地获得资格 .
然而，这确实揭示了另一个方面：法律优先权 . 如果法律优先权暗示您必须使用单向哈希给定您的系统正在构建的行业，那么这是完全不同的 . 这是你用来说服你的顾客的弹药 . 除此之外，最佳建议是提供合理的风险评估，记录您的异议并以最安全的方式实施系统，以满足客户的要求 .
我认为你应该问自己的真正问题是：'我怎样才能更好地说服人？'
我实施多因素身份验证系统，因此对我来说，很自然地认为您可以重置或重建密码，同时暂时使用一个较少的因素来验证用户仅用于重置/重新创建工作流程 . 特别是使用OTP（一次性密码）作为一些附加因素，如果建议的工作流程的时间窗口很短，则可以减轻大部分风险 . 我们为智能手机实现了软件OTP生成器（大多数用户已经整天携带）并取得了巨大的成功 . 在抱怨商业插件出现之前，我所说的是，当它们不是用于验证用户的唯一因素时，我们可以降低保持密码易于检索或重置的固有风险 . 我承认，对于站点场景中的密码重用，情况仍然不是很好，因为用户将坚持使用原始密码，因为他/她也想打开其他站点，但您可以尝试提供重建的密码最安全的方式（htpps和html上的谨慎外观） .
对不起，但只要你有办法解密他们的密码，就没有办法让它变得安全 . 很痛苦地战斗，如果你输了，CYA .
处理丢失/遗忘的密码：
没有人能够恢复密码 .
如果用户忘记了密码，他们必须至少知道他们的用户名或电子邮件地址 . 根据请求，在Users表中生成GUID，并将包含guid链接的电子邮件作为参数发送到用户的电子邮件地址 .
链接后面的页面验证参数guid是否确实存在（可能带有一些超时逻辑），并要求用户输入新密码 .
如果您需要热线帮助用户，请在您的授权模型中添加一些角色，并允许热线角色以已识别的用户身份临时登录 . 记录所有此类热线登录 . 例如，Bugzilla为管理员提供了这样的模拟功能 .
根据我就该问题所作的评论：
几乎每个人都忽略了一个重要的观点...我最初的反应与@迈克尔布鲁克斯非常相似，直到我意识到，像@stefanw一样，这里的问题是破碎的要求，但这些都是它们的本质 .
但是后来发生的事情甚至可能都不是这样！这里缺少的是应用程序资产的未说出的 Value . 只是说来说，对于一个低 Value 的系统，一个完全安全的认证机制，涉及所有的过程，将是过度的，并且是安全的选择 .
显然，对于银行来说，"best practices"是必须的，并且没有办法在道德上违反CWE-257 . 但它只是不值得（但仍然需要一个简单的密码） .
It's important to remember, true security expertise is in finding appropriate tradeoffs, NOT in dogmatically spouting the "Best Practices" that anyone can read online.
因此，我建议另一个解决方案：
根据系统的 Value ， ONLY IF 系统是适当的低 Value ，没有"expensive"资产（身份本身，包括在内）， AND 有有效的业务要求，使正常的过程不可能（或足够困难/昂贵）， AND 客户了解所有警告......
那么简单地允许可逆加密可能是合适的，没有特殊的环节可以跳过 .
我完全没有说过不打算加密，因为它实现起来非常简单/便宜（甚至考虑了可通行的密钥管理），并且它提供了一些保护（超过了实现它的成本） . 此外，它值得研究如何通过电子邮件，在屏幕上显示等方式为用户提供原始密码 .
由于这里的假设是被盗密码的 Value （即使是总计）非常低，因此这些解决方案中的任何一个都是有效的 .
由于正在进行热烈的讨论，实际上是在几个热烈的讨论中，在不同的帖子和单独的评论帖中，我将补充一些说明，并回应一些在这里其他地方提出的非常好的观点 .
首先，我认为's clear to everyone here that allowing the user'的原始密码需要检索，是不良实践，而且通常不是一个好主意 . 这根本不是争议......
此外，我要强调的是，在许多情况下，即使是MOST，情况 - 它确实是错误的，甚至是foul, nasty, AND ugly .
然而，问题的关键在于原则，禁止这样做，如果是这样，如何在 most correct manner appropriate to the situation 中这样做 .
现在，正如@Thomas，@ sfussenegger和其他一些人提到的那样，回答这个问题的唯一正确方法是对任何给定（或假设）的情况进行彻底的风险分析，以了解值得保护的东西以及其他什么 . 缓解措施可以起到保护作用 .
不，它不是一个流行语，这是真实安全专业人员的基本，最重要的工具之一 . 在经过深思熟虑的风险分析后，最佳实践达到了一定程度（通常作为缺乏经验和黑客的指导） .
Y 'know, it'很有趣 - 我一直认为自己是安全狂热分子之一，不知怎的，我是狂热分子，还是真正的现实安全专家 - 我不相信在没有那么重要的风险分析的情况下喷出教条（或CWE） .
"Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against. More security doesn’t necessarily equate to good security."
风险分析和真正的安全狂热分子将指出基于风险，潜在损失，可能的威胁，补充缓解等基于 Value /风险的更明智的权衡 . 任何"Security Expert"都不能指出健全的风险分析作为其基础建议，或支持逻辑权衡，但更愿意在没有理解如何进行风险分析的情况下兜售教条和CWE，除了安全黑客，他们的专业知识不值得他们打印的卫生纸 .
实际上，这就是我们如何得到机场安全的荒谬 .
但在我们谈论在这种情况下做出的适当权衡之前，让我们得到关于这种情况的所有背景信息，我们都假设 - 因为问题是假设的情况可能是......）
让's assume a LOW-VALUE system, yet not so trival that it'的公共访问 - 系统所有者想要防止偶然冒充，但"high"安全性并不像易用性那样至关重要 . （是的，接受任何熟练的脚本小子可能破坏网站的风险是合法的权衡......等等，现在不是APT流行......？）
例如，让's say I'为一个大型家庭聚会安排一个简单的网站，让每个人都能集体讨论今年我们想去野营旅行的地方 . 我非常擅长记住密码，甚至根本不使用电脑......所以我想删除所有可能的摩擦 . 再说一遍，我并不担心黑客，我只是不想要错误登录的愚蠢错误 - 我想知道谁来了，他们想要什么 .
无论如何 .
那么，如果我们对密码进行对称加密，而不是使用单向哈希，那么我们的主要风险是什么呢？
冒充用户？不，我已经接受了这种风险，而不是有趣 .
邪恶的管理员？好吧，也许......但是，我再也不在乎是否有人可以模仿另一个用户，INTERNAL或者没有...而且无论如何恶意管理员都会得到你的密码 no matter what - 如果你的管理员变坏了，无论如何都是游戏 .
已经提出的另一个问题是身份实际上是在多个系统之间共享的 . 啊!这是一个非常有趣的风险，需要仔细观察 .
让我先说声称它不是共享的实际身份，而是证据或身份验证凭证 . 好的，由于共享密码将有效地允许我进入另一个系统（例如，我的银行帐户或gmail），这实际上是相同的身份，因此它只是语义...除非它不是 . 在这种情况下，身份由每个系统单独管理（尽管可能存在第三方ID系统，例如OAuth - 仍然，它与该系统中的身份分开 - 稍后将详细介绍） .
因此，这里的核心风险是，用户愿意将他的（相同）密码输入到几个不同的系统中 - 现在，我（管理员）或我网站的任何其他黑客都可以访问阿姨阿玛的密码核导弹基地 .
嗯 .
这里有什么似乎不适合你吗？
这应该 .
让我们从保护核导弹系统的事实开始，我只是在建造一个frakkin家庭郊游场所（为我的家人） . 那么它的责任是什么呢？嗯......核导弹系统怎么样？咄 .
其次，如果我想窃取某人的密码（知道在安全网站之间重复使用相同密码的人，而不是那么安全的密码） - 为什么我会打扰你的网站呢？或者与对称加密斗争？ Goshdarnitall，我可以张贴my own simple website，让用户注册接收关于他们想要的任何重要新闻... Puffo Presto，我"stole"他们的密码 .
是的，用户教育总是回来咬我们的hienie，不是吗？
你无能为力......即使你想在你的网站上散列他们的密码，并做其他TSA所能想到的一切，你也加密了他们的密码保护，而不是一个白，如果他们这么麻烦 .
换句话说， You don't own their passwords ，所以不要试图像你那样行事 .
所以，亲爱的安全专家，作为一位曾经问温迪的老太太，“哪里有风险？”
另外几点，回答上面提出的一些问题：
CWE不是法律，法规，甚至是标准 . 它是常见弱点的集合，即"Best Practices"的倒数 .
共享身份问题是一个实际问题，但被反对者误解（或歪曲）在这里 . 这是一个共享身份本身的问题（！），而不是破解低 Value 系统上的密码 . 如果您在低 Value 系统和高 Value 系统之间共享密码，问题已经存在！
通过by，对于这些低 Value 系统和高 Value 银行系统，前一点实际上将使用OAuth等指向 AGAINST .
我知道这只是一个例子，但（遗憾的是）FBI系统实际上并不是最安全的 . 不太像你的猫_257991的服务器，但它们也没有超过一些更安全的银行 .
加密密钥的分裂知识或双重控制不仅仅发生在军队中，事实上PCI-DSS现在基本上来自所有商家，所以它不再那么远（如果 Value 合理的话） .
对于那些抱怨这些问题的人来说，开发人员职业看起来如此糟糕的原因是：这些问题使得安全行业看起来更糟糕 . 同样，以业务为中心的风险分析是必需的，否则你会使自己无用 . 除了错误 .
我想这就是它为什么所有的原因 - 但是需要更多的培训 .
呼 . 多长的帖子......
但要回答你原来的问题，@Shane：
向客户解释正确的做事方式 .
如果他仍坚持，再解释一下，坚持，争辩 . 如果需要的话，发脾气 .
向他解释商业风险 . 细节很好，数字更好，现场演示通常是最好的 .
如果他仍然坚持，并提出有效的商业理由 - 是时候进行判断了：
这个网站是否低至无 Value ？这真的是一个有效的商业案例吗？这对你好吗？是否没有其他风险可以考虑，这会超过有效的商业原因？ （当然，客户端不是恶意网站，但多数民众赞成） .
如果是这样，就去吧 . 使用必要的流程并不值得努力，摩擦和失去使用（在这种假设的情况下） . 任何其他决定（再次，在这种情况下）是一个不好的权衡 .
因此，底线和实际答案 - 使用简单的对称算法对其进行加密，使用强ACL保护加密密钥，最好使用DPAPI等保存加密密钥，对其进行记录并让客户（足够高级的人做出决定）签字它 .
迈克尔布鲁克斯对CWE-257一直很直言不讳 - 无论你使用什么方法，你（管理员）仍然可以恢复密码 . 那么这些选择如何：
使用 someone else's public key 加密密码 - 某些外部权限 . 这样你就无法亲自重建它，用户将不得不去做外部权限并要求恢复其密码 .
使用第二个密码短语生成的密钥加密密码 . 执行此加密客户端，并且永远不会将其明确地传输到服务器 . 然后，要恢复，请通过从其输入重新生成密钥再次执行解密客户端 . 不可否认，这种方法基本上是使用第二个密码，但您可以随时告诉他们将其写下来，或使用旧的安全问题方法 .
我认为1.是更好的选择，因为它使您能够指定客户公司内的某人持有私钥 . 确保它们自己生成密钥，并将其与指令一起存储在保险箱等中 . 您甚至可以通过选择仅加密并从密码向内部第三方提供某些字符来增加安全性，这样他们就必须破解密码才能猜到它 . 将这些字符提供给用户，他们可能会记住它是什么！
从我对这个主题的了解，我相信如果你正在 Build 一个带有登录/密码的网站，那么你根本不应该在你的服务器上看到明文密码 . 密码应该在它离开客户端之前进行哈希处理，并且可能是盐渍的 .
如果您从未看到明文密码，则不会出现检索问题 .
此外，我（从网上）收集（据称）某些算法（如MD5）不再被认为是安全的 . 我无法判断自己，但这是需要考虑的事情 .
如何针对这个问题采取另一种方法或角度？问为什么密码必须是明文的：如果它真的需要检索他们设置的密码（他们不记得它是什么），你需要能够给他们一个他们可以使用的密码 .
想一想：如果用户需要检索密码，那是因为他们忘记了密码 . 在这种情况下，新密码与旧密码一样好 . 但是，今天使用的常见密码重置机制的缺点之一是在重置操作中生成的密码通常是一堆随机字符，因此用户很难简单地键入，除非他们复制n-糊 . 对于不那么精明的计算机用户来说，这可能是个问题 .
解决该问题的一种方法是提供或多或少自然语言文本的自动生成的密码 . 虽然自然语言字符串可能没有一串相同长度的随机字符所具有的熵，但仍然可以被任何可以阅读的人识别和输入 . 不同长度的六个随机单词可能比10个随机字符更容易正确且有信心地键入，并且它们也可以具有更高的熵 . 例如，从大写，小写，数字和10个标点符号（总共72个有效符号）中随机抽取的10个字符密码的熵将具有61.7比特的熵 . 使用7776个单词的字典（如Diceware使用的）可以随机选择六个字密码短语，密码短语的熵为77.4位 . 有关详细信息，请参阅Diceware FAQ .
一个约77位熵的密码：“承认散文耀斑表的敏锐天赋”
一个大约74位熵的密码：“K：＆$ R ^ tt~qkD”
我知道我更喜欢输入短语，并且使用copy-n-paste，这个短语也很容易使用密码，所以没有丢失 . 当然，如果您的网站（或任何受保护资产）对于自动生成的密码短语不需要77位熵，则生成较少的单词（我确信您的用户会欣赏） .
我理解存在密码保护资产的论点，这些资产确实没有很高的 Value ，因此破解密码可能不是世界末日 . 例如，我可能不会关心我在各种网站上使用的80％的密码是否被破坏：所有可能发生的事情都是有人发送垃圾邮件或在我的名下发帖一段时间 . 这不会很好，但并不像他们会侵入我的银行账户 . 但是，鉴于许多人使用与他们的银行账户（可能是国家安全数据库）相同的密码用于他们的网站论坛网站，我认为最好将这些“低 Value ”密码处理为非-recoverable .
将用户安全问题的答案作为加密密钥的一部分，并且不要将安全问题答案存储为纯文本（而是使用哈希）
用户是否真的需要恢复（例如被告知）他们忘记的密码是什么，或者他们只是需要能够进入系统？如果他们真正想要的是一个登录密码，为什么不设置一个例程，只需将旧密码（无论是什么）更改为支持人员可以给丢失密码的人的新密码？
我曾经使用过这样做的系统 . 支持人员无法知道当前密码是什么是，但可以将其重置为新值 . 当然，所有这些重置都应记录在某处，良好的做法是向用户生成一封电子邮件，告诉他密码已被重置 .
另一种可能性是允许两个同时密码允许访问帐户 . 一个是用户管理的“普通”密码，另一个是仅由支持人员知道的骨架/主密钥，对所有用户都是相同的 . 这样，当用户遇到问题时，支持人员可以使用主密钥登录帐户并帮助用户将密码更改为任何密码 . 不用说，所有使用主密钥的登录也应该由系统记录 . 作为额外措施，每当使用主密钥时，您也可以验证支持人员凭证 .
-EDIT-回应关于没有主密钥的评论：我同意这是不好的，因为我认为允许除用户以外的任何人访问用户的帐户是不好的 . 如果你看一下这个问题，那么整个前提是客户要求一个高度妥协的安全环境 .
主密钥不必像最初看起来那么糟糕 . 我曾经在一家国防工厂工作，他们认为大型计算机操作员需要在某些场合“特殊访问” . 他们只需将特殊密码放入密封的信封中，然后将其粘贴到操作员的桌面上即可 . 要使用密码（操作员不知道），他必须打开信封 . 在每次轮班更换时，轮班主管的一个工作是查看信封是否已打开，如果是，立即更改密码（由另一个部门更改）并且新密码被放入新信封并且过程全部启动再次 . 将询问操作员他为何打开它并将事件记录在案以供记录 .
虽然这不是我设计的程序，但它确实起作用并提供了出色的问责制 . 一切都被记录和审查，加上所有运营商都有国防部的秘密许可，我们从来没有任何滥用 .
由于审查和监督，所有经营者都知道，如果他们滥用打开信封的特权，他们将立即被解雇并可能受到刑事起诉 .
所以我想真正的答案是，如果一个人想要做正确的事情，就可以雇用他们可以信任的人，进行背景调查，并进行适当的管理监督和问责 .
但是，如果这个可怜的家伙的客户有良好的管理，那么他们一开始就不会要求这样一个安全可靠的解决方案，现在他们呢？
允许用户检索其原始密码的唯一方法是 encrypt it with the user's own public key. 只有该用户才能解密他们的密码 .
所以步骤是：
用户在您的网站上注册（当然是通过SSL）而无需设置密码 . 自动登录或提供临时密码 .
您提供存储其公共PGP密钥以供将来密码检索 .
他们上传他们的公共PGP密钥 .
您要求他们设置新密码 .
他们提交了密码 .
您使用可用的最佳密码哈希算法（例如bcrypt）对密码进行哈希处理 . 验证下次登录时使用此选项 .
使用公钥加密密码，并单独存储 .
如果用户随后要求输入密码，则使用加密（非散列）密码进行响应 . 如果用户以后不希望能够检索他们的密码（他们只能将其重置为服务生成的密码），则可以跳过步骤3和7 .
您可能没有考虑的另一个选择是允许通过电子邮件进行操作这有点麻烦，但是我为一个客户端实现了这一点，该客户端需要用户在系统“外部”查看（只读）系统的某些部分 . 例如：
用户注册后，即可获得完全访问权限（如常规网站） . 注册必须包含电子邮件 .
如果需要数据或操作并且用户不记得他们的密码，他们仍然可以通过单击特殊的“ email me for permission " button, right next to the regular " submit ”按钮来执行操作 .
然后将请求发送到电子邮件，并附带一个超链接，询问他们是否希望执行操作 . 这类似于密码重置电子邮件链接，但它不是重置密码而是执行 one-time action .
然后用户单击"Yes"，它确认应显示数据，或应执行操作，显示数据等 .
正如您在评论中提到的，如果电子邮件遭到破坏，这将无效，但它确实解决了@joachim关于不想重置密码的评论 . 最终，他们必须使用密码重置，但他们可以在更方便的时候，或在管理员或朋友的帮助下，根据需要这样做 .
此解决方案的一个转折是将操作请求发送给第三方受信任的管理员 . 这个会在老年人，精神障碍者，非常年轻或其他困惑的用户的情况下工作得最好 . 当然，这需要这些人的可信管理员来支持他们的行动 .