我应该如何合乎道德地处理用户密码存储以便以后进行明文检索？
随着我继续构建越来越多的网站和 Web 应用程序，我经常被要求以某种方式存储用户的密码，以便在用户遇到问题时可以检索这些密码（通过电子邮件发送忘记的密码链接，引导他们通过当我可以的时候，我会强烈反对这种做法，并且我做了很多“额外”编程，以使密码重置和管理协助成为可能，而无需存储他们的实际密码。
当我无法对抗它（或无法获胜）时，我总是以某种方式对密码进行编码，这样它至少不会以明文形式存储在数据库中——尽管我知道如果我的数据库被黑客入侵罪犯不需要花太多时间就能破解密码，所以这让我感到不舒服。
在完美的世界中，人们会经常更新密码，并且不会在许多不同的网站上重复密码 - 不幸的是，我知道很多人都有相同的工作/家庭/电子邮件/银行密码，甚至在需要帮助时免费将其提供给我。如果我的数据库安全程序由于某种原因失败，我不想成为他们经济损失的负责人。
从道德和伦理上讲，我觉得有责任保护某些用户的生计，即使他们对生计的尊重程度要低得多。 我确信，对于加盐哈希和不同的编码选项，有很多方法和论据，但是当您必须存储它们时，是否有一个“最佳实践”？在几乎所有情况下，我都会使用 PHP 和 MySQL，如果这对我处理细节的方式有任何影响的话。
赏金的附加信息
我想澄清一下，我知道这不是您想要做的事情，并且在大多数情况下拒绝这样做是最好的。然而，我并不是在寻找关于采用这种方法的优点的讲座，而是在寻找如果您确实采用这种方法应采取的最佳步骤。
在下面的注释中，我指出，主要面向老年人、智障人士或幼儿的网站在要求人们执行安全密码恢复例程时可能会让他们感到困惑。尽管在这些情况下我们可能会发现它简单而平凡，但某些用户需要额外的帮助，要么让服务技术帮助他们进入系统，要么将其通过电子邮件/直接显示给他们。
在此类系统中，如果用户没有获得此级别的访问帮助，这些人口统计数据的流失率可能会阻碍应用程序，因此请在回答时考虑到这样的设置。
感谢大家
这是一个有趣的问题，有很多争论，我很喜欢它。最后，我选择了一个答案，既保留密码安全性（我不必保留纯文本或可恢复的密码），又使我指定的用户群可以登录系统，而不会出现我发现的主要缺点正常密码恢复。
与往常一样，出于不同的原因，我想将大约 5 个答案标记为正确，但我必须选择最好的一个 - 其余的都得到 +1。谢谢大家！
另外，感谢 Stack 社区中为这个问题投票和/或将其标记为最爱的每个人。我将 100 票赞成视为一种恭维，并希望这次讨论能够帮助其他与我有同样担忧的人。
As I continue to build more and more websites and web applications I am often asked to store user's passwords in a way that they can be retrieved if/when the user has an issue (either to email a forgotten password link, walk them through over the phone, etc.) When I can I fight bitterly against this practice and I do a lot of ‘extra’ programming to make password resets and administrative assistance possible without storing their actual password.
When I can’t fight it (or can’t win) then I always encode the password in some way so that it, at least, isn’t stored as plaintext in the database—though I am aware that if my DB gets hacked it wouldn't take much for the culprit to crack the passwords, so that makes me uncomfortable.
In a perfect world folks would update passwords frequently and not duplicate them across many different sites—unfortunately I know MANY people that have the same work/home/email/bank password, and have even freely given it to me when they need assistance. I don’t want to be the one responsible for their financial demise if my DB security procedures fail for some reason.
Morally and ethically I feel responsible for protecting what can be, for some users, their livelihood even if they are treating it with much less respect.
I am certain that there are many avenues to approach and arguments to be made for salting hashes and different encoding options, but is there a single ‘best practice’ when you have to store them? In almost all cases I am using PHP and MySQL if that makes any difference in the way I should handle the specifics.
Additional Information for Bounty
I want to clarify that I know this is not something you want to have to do and that in most cases refusal to do so is best. I am, however, not looking for a lecture on the merits of taking this approach I am looking for the best steps to take if you do take this approach.
In a note below I made the point that websites geared largely toward the elderly, mentally challenged, or very young can become confusing for people when they are asked to perform a secure password recovery routine. Though we may find it simple and mundane in those cases some users need the extra assistance of either having a service tech help them into the system or having it emailed/displayed directly to them.
In such systems the attrition rate from these demographics could hobble the application if users were not given this level of access assistance, so please answer with such a setup in mind.
Thanks to Everyone
This has been a fun question with lots of debate and I have enjoyed it. In the end I selected an answer that both retains password security (I will not have to keep plain text or recoverable passwords), but also makes it possible for the user base I specified to log into a system without the major drawbacks I have found from normal password recovery.
As always there were about 5 answers that I would like to have marked as correct for different reasons, but I had to choose the best one--all the rest got a +1. Thanks everyone!
Also, thanks to everyone in the Stack community who voted for this question and/or marked it as a favorite. I take hitting 100 up votes as a compliment and hope that this discussion has helped someone else with the same concern that I had.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（26）
采取另一种方法或角度来解决这个问题怎么样？问为什么密码要求是明文：如果是为了让用户可以检索密码，那么严格来说，你实际上不需要检索他们设置的密码（他们无论如何都不记得它是什么），你需要能够为他们提供一个他们可以使用的密码。
想想看：如果用户需要找回密码，那是因为他们忘记了密码。在这种情况下，新密码与旧密码一样好。但是，当今使用的常见密码重置机制的缺点之一是重置操作中生成的密码通常是一堆随机字符，因此用户很难简单地正确输入，除非他们复制 -粘贴。对于不太懂行的计算机用户来说，这可能是一个问题。
解决该问题的一种方法是提供自动生成的密码，这些密码或多或少是自然语言文本。虽然自然语言字符串可能不具有相同长度的随机字符字符串所具有的熵，但没有任何内容表明您的自动生成的密码只需包含 8 个（或 10 个或 12 个）字符。通过将几个随机单词串在一起来获取高熵自动生成的密码（在它们之间留一个空格，这样任何可以阅读的人仍然可以识别和输入它们）。六个不同长度的随机单词可能比 10 个随机字符更容易正确且自信地键入，并且它们也可以具有更高的熵。例如，从大写字母、小写字母、数字和 10 个标点符号（总共 72 个有效符号）中随机抽取的 10 个字符密码的熵将为 61.7 位。使用包含 7776 个单词的字典（如 Diceware 使用的），可以为六个单词的密码短语随机选择该字典，该密码短语的熵将为 77.4 位。有关详细信息，请参阅 Diceware 常见问题解答。
大约 77 位熵的密码：“Admit Prose Flare Table Acute Flair”
大约 74 位的密码熵：“K：&$R^tt~qkD”
我知道我更喜欢输入短语，通过复制粘贴，该短语的使用并不比密码简单，因此不会造成任何损失。当然，如果您的网站（或任何受保护的资产）不需要 77 位熵来自动生成密码，请生成更少的单词（我相信您的用户会喜欢这一点）。
我理解这样的论点：受密码保护的资产实际上没有很高的价值，因此密码泄露可能不会是世界末日。例如，我可能不会关心我在各个网站上使用的 80% 的密码是否被泄露：可能发生的只是有人在一段时间内以我的名义发送垃圾邮件或发帖。那不太好，但他们不会闯入我的银行账户。然而，考虑到许多人在他们的网络论坛网站上使用与他们的银行帐户（可能还有国家安全数据库）相同的密码，我认为最好将那些“低价值”密码作为非密码来处理。 -可恢复。
How about taking another approach or angle at this problem? Ask why the password is required to be in plaintext: if it's so that the user can retrieve the password, then strictly speaking you don't really need to retrieve the password they set (they don't remember what it is anyway), you need to be able to give them a password they can use.
Think about it: if the user needs to retrieve the password, it's because they've forgotten it. In which case a new password is just as good as the old one. But, one of the drawbacks of common password reset mechanisms used today is that the generated passwords produced in a reset operation are generally a bunch of random characters, so they're difficult for the user to simply type in correctly unless they copy-n-paste. That can be a problem for less savvy computer users.
One way around that problem is to provide auto-generated passwords that are more or less natural language text. While natural language strings might not have the entropy that a string of random characters of the same length has, there's nothing that says your auto-generated password needs to have only 8 (or 10 or 12) characters. Get a high-entropy auto-generated passphrase by stringing together several random words (leave a space between them, so they're still recognizable and typeable by anyone who can read). Six random words of varying length are probably easier to type correctly and with confidence than 10 random characters, and they can have a higher entropy as well. For example, the entropy of a 10 character password drawn randomly from uppercase, lowercase, digits and 10 punctuation symbols (for a total of 72 valid symbols) would have an entropy of 61.7 bits. Using a dictionary of 7776 words (as Diceware uses) which could be randomly selected for a six word passphrase, the passphrase would have an entropy of 77.4 bits. See the Diceware FAQ for more info.
a passphrase with about 77 bits of entropy: "admit prose flare table acute flair"
a password with about 74 bits of entropy: "K:&$R^tt~qkD"
I know I'd prefer typing the phrase, and with copy-n-paste, the phrase is no less easy to use that the password either, so no loss there. Of course if your website (or whatever the protected asset is) doesn't need 77 bits of entropy for an auto-generated passphrase, generate fewer words (which I'm sure your users would appreciate).
I understand the arguments that there are password protected assets that really don't have a high level of value, so the breach of a password might not be the end of the world. For example, I probably wouldn't care if 80% of the passwords I use on various websites was breached: all that could happen is a someone spamming or posting under my name for a while. That wouldn't be great, but it's not like they'd be breaking into my bank account. However, given the fact that many people use the same password for their web forum sites as they do for their bank accounts (and probably national security databases), I think it would be best to handle even those 'low-value' passwords as non-recoverable.
想象一下，有人委托建造一座大型建筑 - 比方说，是一家酒吧 - 并且发生以下对话：
建筑师： 对于这种规模和容量的建筑，您将需要消防出口这里，这里，还有这里。
客户： 不，维护起来太复杂且昂贵，我不想要任何侧门或后门。
建筑师： 先生，消防出口不是可选的，而是根据城市消防法规所必需的。
客户： 我付钱给你不是为了争论。按照我的要求去做。
然后建筑师会问如何在没有消防出口的情况下合乎道德地建造这座建筑吗？
在建筑和工程行业，对话最有可能像这样结束：
建筑师：如果没有消防出口，这座建筑就无法建造。您可以去找任何其他有执照的专业人士，他也会告诉您同样的事情。我现在要走了；当您准备好合作时给我回电话。
计算机编程可能不是一个获得许可的职业，但人们似乎常常想知道为什么我们的职业没有得到与公民或公民相同的尊重机械工程师 - 好吧，别再犹豫了。这些职业在收到垃圾（或完全危险的）要求时，会简单地拒绝。他们知道这不是说“好吧，我尽力了，但他坚持，我必须按他说的做”的借口。他们可能会因此而失去驾照。
我不知道您或您的客户是否属于任何上市公司，但以任何可恢复的形式存储密码将导致您无法通过几种不同类型的安全审核。问题不在于对于某些有权访问您的数据库的“黑客”来说恢复密码有多困难。 绝大多数安全威胁都是内部的。您需要防范的是一些心怀不满的员工带走所有密码并将其卖给最高出价者。使用非对称加密并将私钥存储在单独的数据库中绝对无法阻止这种情况；总会有人能够访问私有数据库，这是一个严重的安全风险。
没有道德或负责任的方式以可恢复的形式存储密码。期间。
Imagine someone has commissioned a large building to be built - a bar, let's say - and the following conversation takes place:
Architect: For a building of this size and capacity, you will need fire exits here, here, and here.
Client: No, that's too complicated and expensive to maintain, I don't want any side doors or back doors.
Architect: Sir, fire exits are not optional, they are required as per the city's fire code.
Client: I'm not paying you to argue. Just do what I asked.
Does the architect then ask how to ethically build this building without fire exits?
In the building and engineering industry, the conversation is most likely to end like this:
Architect: This building cannot be built without fire exits. You can go to any other licensed professional and he will tell you the same thing. I'm leaving now; call me back when you are ready to cooperate.
Computer programming may not be a licensed profession, but people often seem to wonder why our profession doesn't get the same respect as a civil or mechanical engineer - well, look no further. Those professions, when handed garbage (or outright dangerous) requirements, will simply refuse. They know it is not an excuse to say, "well, I did my best, but he insisted, and I've gotta do what he says." They could lose their license for that excuse.
I don't know whether or not you or your clients are part of any publicly-traded company, but storing passwords in any recoverable form would cause you to to fail several different types of security audits. The issue is not how difficult it would be for some "hacker" who got access to your database to recover the passwords. The vast majority of security threats are internal. What you need to protect against is some disgruntled employee walking off with all the passwords and selling them to the highest bidder. Using asymmetrical encryption and storing the private key in a separate database does absolutely nothing to prevent this scenario; there's always going to be someone with access to the private database, and that's a serious security risk.
There is no ethical or responsible way to store passwords in a recoverable form. Period.
您可以使用公钥加密密码+盐。对于登录，只需检查存储的值是否等于根据用户输入+盐计算的值。如果有时间需要以明文形式恢复密码，可以使用私钥手动或半自动解密。私钥可以存储在其他地方，并且可以另外进行对称加密（然后需要人工交互来解密密码）。
我认为这实际上有点类似于 Windows 恢复代理 的工作方式。
You could encrypt the password + a salt with a public key. For logins just check if the stored value equals the value calculated from the user input + salt. If there comes a time, when the password needs to be restored in plaintext, you can decrypt manually or semi-automatically with the private key. The private key may be stored elsewhere and may additionally be encrypted symmetrically (which will need a human interaction to decrypt the password then).
I think this is actually kind of similar to the way the Windows Recovery Agent works.
不要放弃。您可以用来说服客户的武器是不可否认性。如果您可以通过任何机制重建用户密码，您就为他们的客户提供了合法的不可否认机制，他们可以否认任何依赖于该密码的交易，因为供应商无法证明这一点他们没有重建密码并自行完成交易。如果密码正确存储为摘要而不是密文，则这是不可能的，因为最终客户端自己执行交易或违反了密码的注意义务。无论哪种情况，责任都由他承担。我曾经处理过价值数亿美元的案件。这不是你想出错的事情。
Don't give up. The weapon you can use to convince your clients is non-repudiability. If you can reconstruct user passwords via any mechanism, you have given their clients a legal non-repudiation mechanism and they can repudiate any transaction that depends on that password, because there is no way the supplier can prove that they didn't reconstruct the password and put the transaction through themselves. If passwords are correctly stored as digests rather than ciphertext, this is impossible, ergo either the end-client executed the transaction himself or breached his duty of care w.r.t. the password. In either case that leaves the liability squarely with him. I've worked on cases where that would amount to hundreds of millions of dollars. Not something you want to get wrong.
您不能合乎道德地存储密码以供以后进行明文检索。就这么简单。即使乔恩·斯基特（Jon Skeet）也无法合乎道德地存储密码以供以后进行明文检索。如果您的用户可以以某种方式检索纯文本密码，那么在您的代码中发现安全漏洞的黑客也可能如此。这不仅仅是一个用户的密码被泄露，而是所有用户的密码被泄露。
如果您的客户对此有疑问，请告诉他们可恢复地存储密码是违法的。无论如何，在英国，1998 年《数据保护法》（特别是附表 1 第二部分第 9 款）要求数据控制者使用适当的技术措施来保证个人数据的安全，除其他外，考虑到如果数据泄露可能造成的损害——对于在站点之间共享密码的用户来说，这可能是相当大的。如果他们仍然无法理解这是一个问题，请向他们指出一些现实世界的例子，例如 这个。
允许用户恢复登录的最简单方法是通过电子邮件向他们发送一个一次性链接，该链接会自动登录并直接将他们带到可以选择新密码的页面。创建一个原型并向他们展示它的实际效果。
以下是我就该主题撰写的几篇博客文章：
更新：我们现在开始看到针对未能保护其用户安全的公司的诉讼和起诉正确设置密码。示例：LinkedIn 遭受 500 万美元集体诉讼； 索尼因 PlayStation 数据黑客攻击被罚款 25 万英镑。如果我没记错的话，LinkedIn 实际上正在对其用户的密码进行加密，但它使用的加密技术太弱，无法发挥作用。
You can not ethically store passwords for later plaintext retrieval. It's as simple as that. Even Jon Skeet can not ethically store passwords for later plaintext retrieval. If your users can retrieve passwords in plain text somehow or other, then potentially so too can a hacker who finds a security vulnerability in your code. And that's not just one user's password being compromised, but all of them.
If your clients have a problem with that, tell them that storing passwords recoverably is against the law. Here in the UK at any rate, the Data Protection Act 1998 (in particular, Schedule 1, Part II, Paragraph 9) requires data controllers to use the appropriate technical measures to keep personal data secure, taking into account, among other things, the harm that might be caused if the data were compromised -- which might be considerable for users who share passwords among sites. If they still have trouble grokking the fact that it's a problem, point them to some real-world examples, such as this one.
The simplest way to allow users to recover a login is to e-mail them a one-time link that logs them in automatically and takes them straight to a page where they can choose a new password. Create a prototype and show it in action to them.
Here are a couple of blog posts I wrote on the subject:
Update: we are now starting to see lawsuits and prosecutions against companies that fail to secure their users' passwords properly. Example: LinkedIn slapped with $5 million class action lawsuit; Sony fined £250,000 over PlayStation data hack. If I recall correctly, LinkedIn was actually encrypting its users' passwords, but the encryption it was using was too weak to be effective.
读完这一部分后：
我想知道这些要求是否强制要求可检索的密码系统。例如：
梅布尔阿姨打电话来说“你的互联网程序无法运行，我不知道我的密码”。 “好的，”客户服务无人机说，“让我检查一些详细信息，然后我会给您一个新密码。当您下次登录时，它会询问您是否要保留该密码或将其更改为您更容易记住的内容。”
然后，系统设置为知道何时发生密码重置并显示“您想保留新密码还是选择新密码”消息。
对于不太懂电脑的人来说，这比被告知他们的旧密码更糟糕吗？虽然客户服务人员可能会搞恶作剧，但数据库本身更安全，以防被破坏。
评论我的建议中的哪些不好的地方，我将建议一个真正满足您最初想要的解决方案。
After reading this part:
I'm left wondering if any of these requirements mandate a retrievable password system. For instance:
Aunt Mabel calls up and says "Your internet program isn't working, I don't know my password". "OK" says the customer service drone "let me check a few details and then I'll give you a new password. When you next log in it will ask you if you want to keep that password or change it to something you can remember more easily."
Then the system is set up to know when a password reset has happened and display a "would you like to keep the new password or choose a new one" message.
How is this worse for the less PC-literate than being told their old password? And while the customer service person can get up to mischief, the database itself is much more secure in case it is breached.
Comment what's bad on my suggestion and I'll suggest a solution that actually does what you initially wanted.
Michael Brooks 对 CWE-257 一直直言不讳 - 事实上，无论您使用什么方法，您（管理员）仍然可以恢复密码。那么这些选项怎么样：
我认为 1. 是更好的选择，因为它使您能够指定客户公司内的某人持有私钥。确保他们自己生成密钥，并将其与说明一起存储在保险箱等中。您甚至可以通过选择仅加密并将密码中的某些字符提供给内部第三方来增加安全性，这样他们就必须破解密码才能猜测它。将这些字符提供给用户，他们可能会记住它是什么！
Michael Brooks has been rather vocal about CWE-257 - the fact that whatever method you use, you (the administrator) can still recover the password. So how about these options:
I think 1. is the better choice, because it enables you to designate someone within the client's company to hold the private key. Make sure they generate the key themselves, and store it with instructions in a safe etc. You could even add security by electing to only encrypt and supply certain characters from the password to the internal third party so they would have to crack the password to guess it. Supplying these characters to the user, they will probably remember what it was!
在回答这个问题时，已经有很多关于用户安全问题的讨论，但我想补充一下好处。到目前为止，我还没有看到在系统上存储可恢复密码所带来的任何合法好处。考虑一下：
似乎唯一可以从可恢复密码中受益的是那些有恶意的人或需要第三方密码交换的不良 API 的支持者（请永远不要使用上述 API！）。也许您可以通过向客户如实陈述通过存储可恢复的密码，公司不会获得任何好处，只会承担责任来赢得争论。
阅读这些类型的请求的字里行间，您会发现您的客户可能不理解甚至根本不关心密码的管理方式。他们真正想要的是一个对用户来说不那么困难的身份验证系统。因此，除了告诉他们实际上并不想要可恢复的密码之外，您还应该为他们提供一些方法，使身份验证过程不那么痛苦，特别是如果您不需要银行等严格的安全级别
但是，如果您出于某种原因（请告诉我们原因）真的、真的、真的需要能够拥有可恢复的密码，您可以通过以下方式保护用户免遭潜在的其他在线帐户泄露：为他们提供一个非基于密码的身份验证系统。因为人们已经熟悉用户名/密码系统，并且它们是一个经过良好实践的解决方案，所以这将是最后的手段，但肯定有很多创造性的密码替代方案：
There's been a lot of discussion of security concerns for the user in response to this question, but I'd like to add a mentioning of benefits. So far, I've not seen one legitimate benefit mentioned for having a recoverable password stored on the system. Consider this:
It seems the only ones that can benefit from recoverable passwords are those with malicious intent or supporters of poor APIs that require third-party password exchange (please don't use said APIs ever!). Perhaps you can win your argument by truthfully stating to your clients that the company gains no benefits and only liabilities by storing recoverable passwords.
Reading between the lines of these types of requests, you'll see that your clients probably don't understand or actually even care at all about how passwords are managed. What they really want is an authentication system that isn't so hard for their users. So in addition to telling them how they don't actually want recoverable passwords, you should offer them ways to make the authentication process less painful, especially if you don't need the heavy security levels of, say, a bank:
But if you, for some reason (and please tell us the reason) really, really, really need to be able to have a recoverable password, you could shield the user from potentially compromising their other online accounts by giving them a non-password-based authentication system. Because people are already familiar with username/password systems and they are a well-exercised solution, this would be a last resort, but there's surely plenty of creative alternatives to passwords:
根据我对这个问题的评论：
几乎每个人都忽略了一个重要的一点...我最初的反应与@Michael Brooks 非常相似，直到我像@stefanw 一样意识到这里的问题是破坏的需求，但这些就是它们的本质。
但后来，我突然想到，情况可能并非如此！这里缺少的一点是应用程序资产的不言而喻的价值。简单地说，对于一个低价值的系统，完全安全的身份验证机制以及涉及的所有流程都将是矫枉过正，并且是错误的安全选择。
显然，对于银行来说，“最佳实践”是必须的，并且没有办法在道德上违反CWE-257。但很容易想到低价值的系统是不值得的（但仍然需要一个简单的密码）。
重要的是要记住，真正的安全专业知识在于找到适当的权衡，而不是教条地宣扬任何人都可以在线阅读的“最佳实践”。
因此，我建议另一种解决方案：
根据系统的价值，仅当系统的价值适当低且没有“昂贵”资产（包括身份本身），并且有有效的业务要求使正确的流程变得不可能（或足够困难/昂贵），并且客户了解所有注意事项...
那么简单地允许可逆加密可能是合适的，没有特殊的障碍可以跳过。
我只是想说根本不用担心加密，因为它的实现非常简单/便宜（即使考虑到可行的密钥管理），而且它确实提供了一些保护（超过了实现它的成本）。此外，值得研究的是如何向用户提供原始密码，无论是通过电子邮件、在屏幕上显示等。
由于这里的假设是被盗密码的价值（即使是总量）非常低，因此这些解决方案中的任何一个都可以是有效的。
由于正在进行热烈的讨论，实际上是几个热烈的讨论，在不同的帖子和单独的评论线程中，我将添加一些澄清，并回应这里其他地方提出的一些非常好的观点。
首先，我认为这里的每个人都清楚，允许检索用户的原始密码是一种不好的做法，而且通常不是一个好主意。这根本没有争议......
此外，我要强调的是，在许多情况下，大多数情况下 - 这确实是错误的，甚至犯规、令人讨厌，而且丑陋。
但问题的关键在于原则，是否存在不需要禁止的情况，如果是的话，该如何禁止？ 适合情况的最正确方式。
现在，正如 @Thomas、@sfussenegger 和其他一些人提到的，回答这个问题的唯一正确方法是对任何给定（或假设）情况进行彻底的风险分析，以了解什么是利害攸关的、它值得保护多少，以及还有哪些其他缓解措施可以提供这种保护。
不，这不是一个流行词，这是现实安全专业人员的基本、最重要的工具之一。最佳实践在一定程度上是好的（通常作为缺乏经验和黑客的指南），在那之后，深思熟虑的风险分析就开始发挥作用。
你知道，这很有趣 - 我一直认为自己是安全狂热分子之一，但不知怎的，我站在那些所谓的“安全专家”的对立面......好吧，事实是 - 因为我是一个狂热分子，和一个真正的现实生活中的安全专家 - 我不相信在没有最重要的风险分析的情况下大肆宣扬“最佳实践”教条（或 CWE）。
“要小心安全狂热分子，他们会快速应用工具带中的所有内容，而不知道他们要防御的实际问题是什么。更高的安全性并不一定等于良好的安全性。”
风险分析和真正的安全狂热分子会根据风险、潜在损失、可能的威胁、补充缓解措施等，提出更明智的、基于价值/风险的权衡。任何无法指出合理的风险分析的“安全专家”他们的建议的基础，或支持逻辑权衡，但更喜欢滔滔不绝地宣扬教条，而 CWE 甚至不了解如何进行风险分析，只不过是安全黑客，他们的专业知识不值得他们印在卫生纸上。
事实上，这就是我们如何得到机场安全的荒谬之处。
但在我们讨论在这种情况下做出适当的权衡之前，让我们看一下明显的风险（显然，因为我们没有关于这种情况的所有背景信息，所以我们都在假设 - 因为问题是假设的是什么）情况可能有...）
让我们假设一个低价值系统，但又不那么简单，以至于可以公开访问——系统所有者希望防止随意冒充，但“高”安全性并不像易用性那么重要。 （是的，接受任何熟练的脚本小子都可以破解该网站的风险是一个合理的权衡……等等，APT 现在不是很流行吗……？）
举个例子，假设我正在为大型家庭聚会安排一个简单的场地，让每个人都可以集思广益，讨论今年我们想去哪里露营。我不太担心一些匿名黑客，甚至弗雷德表弟反复提出返回旺塔纳马纳比基利基湖的建议，因为我担心艾尔玛阿姨在需要时无法登录。现在，艾尔玛阿姨作为一名核物理学家，不太擅长记住密码，甚至根本不擅长使用计算机……所以我想消除她可能遇到的所有摩擦。再说一遍，我并不担心黑客攻击，我只是不想犯错误登录的愚蠢错误 - 我想知道谁来了，以及他们想要什么。
无论如何。
那么，如果我们对称加密密码而不是使用单向哈希，那么我们的主要风险是什么？
首先我要断言，共享的不是实际的身份，而是证明或身份验证凭证。好吧，由于共享密码将有效地允许我进入另一个系统（例如，我的银行帐户或 gmail），这实际上是相同的身份，所以这只是语义......除了它不是 。在这种情况下，身份由每个系统单独管理（尽管可能存在第三方 ID 系统，例如 OAuth - 尽管如此，它与该系统中的身份是分开的 - 稍后会详细介绍）。
因此，这里的核心风险点是，用户会愿意将他的（相同的）密码输入到几个不同的系统中 - 现在，我（管理员）或我网站的任何其他黑客都可以访问 Erma 阿姨的密码核导弹基地。
嗯。
您觉得这里有什么不对劲吗？
它应该。
首先，保护核导弹系统不是我的责任，我只是在建造一个弗拉金家庭郊游场地（为我的家人）。那么这是谁的责任呢？嗯...核导弹系统怎么样？呃。
其次，如果我想窃取某人的密码（众所周知，某人在安全站点和不那么安全的站点之间重复使用相同的密码） - 为什么我要费心破解您的站点？或者在对称加密方面苦苦挣扎？天哪，我可以建立我自己的简单网站，让用户注册以接收有关他们的任何内容的非常重要的新闻想要……Puffo Presto，我“偷”了他们的密码。
是的，用户教育总是会反过来咬我们，不是吗？
您对此无能为力...即使您要在您的网站上对他们的密码进行哈希处理，并执行 TSA 能想到的所有其他操作，您也为他们的密码添加了保护不是一点，如果他们继续乱七八糟地将密码粘贴到他们遇到的每个网站上。甚至不用费心去尝试。
换句话说，您不拥有他们的密码，因此请停止尝试像您一样行事。
所以，亲爱的安全专家们，正如一位老太太过去常问温迪的那样，“风险在哪里？”
另外几点，针对上面提出的一些问题：
呼。好长的帖子...
但为了回答你原来的问题，@Shane：
该网站的价值是否很低甚至没有？这真的是一个有效的商业案例吗？这对你来说足够好吗？您是否没有可以考虑的其他风险比有效的商业原因更重要？ （当然，客户端不是恶意站点，但那是废话）。
如果是这样，那就继续吧。为了将必要的流程落实到位而付出的努力、摩擦和损失的使用（在这种假设的情况下）是不值得的。任何其他决定（同样，在这种情况下）都是一个糟糕的权衡。
因此，底线和实际答案 - 使用简单的对称算法对其进行加密，使用强大的 ACL 和最好的 DPAPI 等保护加密密钥，记录它并让客户（足够高级的人来做出该决定）签署它。
Pursuant to the comment I made on the question:
One important point has been very glossed over by nearly everyone... My initial reaction was very similar to @Michael Brooks, till I realized, like @stefanw, that the issue here is broken requirements, but these are what they are.
But then, it occured to me that that might not even be the case! The missing point here, is the unspoken value of the application's assets. Simply speaking, for a low value system, a fully secure authentication mechanism, with all the process involved, would be overkill, and the wrong security choice.
Obviously, for a bank, the "best practices" are a must, and there is no way to ethically violate CWE-257. But it's easy to think of low value systems where it's just not worth it (but a simple password is still required).
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.
As such, I suggest another solution:
Depending on the value of the system, and ONLY IF the system is appropriately low-value with no "expensive" asset (the identity itself, included), AND there are valid business requirements that make proper process impossible (or sufficiently difficult/expensive), AND the client is made aware of all the caveats...
Then it could be appropriate to simply allow reversible encryption, with no special hoops to jump through.
I am stopping just short of saying not to bother with encryption at all, because it is very simple/cheap to implement (even considering passible key management), and it DOES provide SOME protection (more than the cost of implementing it). Also, its worth looking at how to provide the user with the original password, whether via email, displaying on the screen, etc.
Since the assumption here is that the value of the stolen password (even in aggregate) is quite low, any of these solutions can be valid.
Since there is a lively discussion going on, actually SEVERAL lively discussions, in the different posts and seperate comment threads, I will add some clarifications, and respond to some of the very good points that have been raised elsewhere here.
To start, I think it's clear to everyone here that allowing the user's original password to be retrieved, is Bad Practice, and generally Not A Good Idea. That is not at all under dispute...
Further, I will emphasize that in many, nay MOST, situations - it's really wrong, even foul, nasty, AND ugly.
However, the crux of the question is around the principle, IS there any situation where it might not be necessary to forbid this, and if so, how to do so in the most correct manner appropriate to the situation.
Now, as @Thomas, @sfussenegger and few others mentioned, the only proper way to answer that question, is to do a thorough risk analysis of any given (or hypothetical) situation, to understand what's at stake, how much it's worth to protect, and what other mitigations are in play to afford that protection.
No, it is NOT a buzzword, this is one of the basic, most important tools for a real-live security professional. Best practices are good up to a point (usually as guidelines for the inexperienced and the hacks), after that point thoughtful risk analysis takes over.
Y'know, it's funny - I always considered myself one of the security fanatics, and somehow I'm on the opposite side of those so-called "Security Experts"... Well, truth is - because I'm a fanatic, and an actual real-life security expert - I do not believe in spouting "Best Practice" dogma (or CWEs) WITHOUT that all-important risk analysis.
"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."
Risk analysis, and true security fanatics, would point to a smarter, value/risk -based tradeoff, based on risk, potential loss, possible threats, complementary mitigations, etc. Any "Security Expert" that cannot point to sound risk analysis as the basis for their recommendations, or support logical tradeoffs, but would instead prefer to spout dogma and CWEs without even understanding how to perform a risk analysis, are naught but Security Hacks, and their Expertise is not worth the toilet paper they printed it on.
Indeed, that is how we get the ridiculousness that is Airport Security.
But before we talk about the appropriate tradeoffs to make in THIS SITUATION, let's take a look at the apparent risks (apparent, because we don't have all the background information on this situation, we are all hypothesizing - since the question is what hypothetical situation might there be...)
Let's assume a LOW-VALUE system, yet not so trival that it's public access - the system owner wants to prevent casual impersonation, yet "high" security is not as paramount as ease of use. (Yes, it is a legitimate tradeoff to ACCEPT the risk that any proficient script-kiddie can hack the site... Wait, isn't APT in vogue now...?)
Just for example, let's say I'm arranging a simple site for a large family gathering, allowing everyone to brainstorm on where we want to go on our camping trip this year. I'm less worried about some anonymous hacker, or even Cousin Fred squeezing in repeated suggestions to go back to Lake Wantanamanabikiliki, as I am about Aunt Erma not being able to logon when she needs to. Now, Aunt Erma, being a nuclear physicist, isn't very good at remembering passwords, or even with using computers at all... So I want to remove all friction possible for her. Again, I'm NOT worried about hacks, I just dont want silly mistakes of wrong login - I want to know who is coming, and what they want.
Anyway.
So what are our main risks here, if we symmetrically encrypt passwords, instead of using a one-way hash?
Let me start by asserting that it's not the actual identity thats shared, rather the proof, or the authentication credential. Okay, since a shared password will effectively allow me entrance to another system (say, my bank account, or gmail), this is effectively the same identity, so it's just semantics... Except that it's not. Identity is managed seperately by each system, in this scenario (though there might be third party id systems, such as OAuth - still, its seperate from the identity in this system - more on this later).
As such, the core point of risk here, is that the user will willingly input his (same) password into several different systems - and now, I (the admin) or any other hacker of my site will have access to Aunt Erma's passwords for the nuclear missile site.
Hmmm.
Does anything here seem off to you?
It should.
Let's start with the fact that protecting the nuclear missiles system is not my responsibility, I'm just building a frakkin family outing site (for MY family). So whose responsibility IS it? Umm... How about the nuclear missiles system? Duh.
Second, If I wanted to steal someone's password (someone who is known to repeatedly use the same password between secure sites, and not-so-secure ones) - why would I bother hacking your site? Or struggling with your symmetric encryption? Goshdarnitall, I can just put up my own simple website, have users sign up to receive VERY IMPORTANT NEWS about whatever they want... Puffo Presto, I "stole" their passwords.
Yes, user education always does come back to bite us in the hienie, doesn't it?
And there's nothing you can do about that... Even if you WERE to hash their passwords on your site, and do everything else the TSA can think of, you added protection to their password NOT ONE WHIT, if they're going to keep promiscuously sticking their passwords into every site they bump into. Don't EVEN bother trying.
Put another way, You don't own their passwords, so stop trying to act like you do.
So, my Dear Security Experts, as an old lady used to ask for Wendy's, "WHERE's the risk?"
Another few points, in answer to some issues raised above:
Whew. What a long post...
But to answer your original question, @Shane:
Is this site low-to-no-value? Is it really a valid business case? Is it good enough for you? Are there no other risks you can consider, that would outweigh valid business reasons? (And of course, is the client NOT a malicious site, but thats duh).
If so, just go right ahead. It's not worth the effort, friction, and lost usage (in this hypothetical situation) to put the necessary process in place. Any other decision (again, in this situation) is a bad tradeoff.
So, bottom line, and an actual answer - encrypt it with a simple symmetrical algorithm, protect the encryption key with strong ACLs and preferably DPAPI or the like, document it and have the client (someone senior enough to make that decision) sign off on it.
中途之家怎么样？
使用强加密方式存储密码，并且不要启用重置。
允许发送一次性密码（必须在第一次登录后立即更改），而不是重置密码。然后让用户更改为他们想要的任何密码（如果他们选择，则为前一个密码）。
您可以将其作为重置密码的安全机制来“出售”。
How about a halfway house?
Store the passwords with a strong encryption, and don't enable resets.
Instead of resetting passwords, allow sending a one-time password (that has to be changed as soon as the first logon occurs). Let the user then change to whatever password they want (the previous one, if they choose).
You can "sell" this as a secure mechanism for resetting passwords.
允许用户检索其原始密码的唯一方法是使用用户自己的公钥对其进行加密。只有该用户才能解密其密码。
因此步骤是：
如果用户随后询问其密码，您将使用加密（未散列）的密码进行响应。如果用户不希望将来能够检索其密码（他们只能将其重置为服务生成的密码），则可以跳过步骤 3 和 7。
The only way to allow a user to retrieve their original password, is to encrypt it with the user's own public key. Only that user can then decrypt their password.
So the steps would be:
Should the user then ask for their password, you respond with the encrypted (not hashed) password. If the user does not wish to be able to retrieve their password in future (they would only be able to reset it to a service-generated one), steps 3 and 7 can be skipped.
我认为你应该问自己的真正问题是：“我怎样才能更好地说服别人？”
I think the real question you should ask yourself is: 'How can I be better at convincing people?'
我有同样的问题。同样，我始终认为有人入侵我的系统，这不是“如果”的问题，而是“何时”的问题。
因此，当我必须创建一个需要存储可恢复机密信息（例如信用卡或密码）的网站时，我所做的就是：
当需要检索此信息时data 只需使用“openssl_decrypt()”函数并询问用户答案。例如：“要接收密码，请回答问题：您的手机号码是什么？”
PS 1：切勿使用数据库中存储的数据作为密码。如果您需要存储用户手机号码，则切勿使用此信息对数据进行编码。始终使用只有用户知道或非亲属很难知道的信息。
PS 2：对于信用卡信息，比如“一键购买”，我所做的是使用登录密码。该密码在数据库中进行哈希处理（sha1、md5 等），但在登录时，我将纯文本密码存储在会话中或非持久（即内存中）安全 cookie 中。这个简单的密码永远不会保留在数据库中，实际上它总是保留在内存中，在部分末尾被销毁。当用户单击“一键购买”按钮时，系统将使用此密码。如果用户使用 facebook、twitter 等服务登录，那么我在购买时再次提示输入密码（好吧，这不是完全“点击”），或者然后使用用户用于登录的服务的一些数据（如 Facebook ID）。
I have the same issue. And at the same way I always think that someone hack my system it's not a matter of "if" but of "when".
So, when I must to do a website that need to store a recoverable confidential information, like a credit card or a password, what I do it's:
When necessary to retrive this data just use the "openssl_decrypt()" function and ask the user for the answer. E.g.: "To receive your password answer the question: What's your cellphone number?"
PS 1: never use as a password a data stored in database. If you need to store the user cellphone number, then never use this information to encode the data. Always use a information that only the user know or that it's hard to someone non-relative know.
PS 2: for credit card information, like "one click buying", what I do is use the login password. This password is hashed in database (sha1, md5, etc), but at login time I store the plain-text password in session or in a non-persistent (i.e. at memory) secure cookie. This plain password never stay in database, indeed it's always stay in memory, destroyed at end of section. When the user click at "one click buying" 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's not a fully "on click") or then use some data of the service that user used to login (like the facebook id).
保护凭证不是二元运算：安全/不安全。安全性与风险评估有关，并且是连续测量的。安全狂热分子不愿意这样想，但丑陋的事实是没有什么是绝对安全的。具有严格密码要求、DNA 样本和视网膜扫描的哈希密码更安全，但会牺牲开发和用户体验。明文密码的安全性要低得多，但实施起来更便宜（但应该避免）。归根结底，这取决于对违规行为的成本/效益分析。您可以根据受保护数据的价值及其时间价值来实施安全性。
某人的密码泄露的代价是多少？在给定系统中模仿的成本是多少？对于联邦调查局的计算机来说，成本可能是巨大的。对于鲍勃的一次性五页网站来说，成本可以忽略不计。专业人士为客户提供选择，并在安全方面列出任何实施的优点和风险。如果客户要求的东西可能因不遵守行业标准而使他们面临风险，情况就更是如此。如果客户特别要求双向加密，我会确保您记录您的反对意见，但这不应阻止您以您知道的最佳方式实施。归根结底，这是客户的钱。是的，您应该推动使用单向哈希，但说这绝对是唯一的选择并且其他任何选择都是不道德的，这完全是无稽之谈。
如果您使用双向加密存储密码，则安全性全部取决于密钥管理。 Windows 提供了限制管理帐户和密码访问证书私钥的机制。如果您在其他平台上托管，则需要查看这些平台上有哪些可用选项。正如其他人所建议的，您可以使用非对称加密。
据我所知，没有任何法律（英国的数据保护法）明确规定密码必须使用单向哈希值存储。这些法律的唯一要求就是采取合理安全措施。如果对数据库的访问受到限制，即使是纯文本密码也可以在此类限制下合法获得资格。
然而，这确实揭示了另一个方面：法律优先权。如果法律优先权表明您必须在构建系统的行业中使用单向哈希，那么情况就完全不同了。这是你用来说服客户的弹药。除此之外，最好的建议是提供合理的风险评估，记录您的反对意见，并根据客户的要求以最安全的方式实施系统。
Securing credentials is not a binary operation: secure/not secure. Security is all about risk assessment and is measured on a continuum. Security fanatics hate to think this way, but the ugly truth is that nothing is perfectly secure. Hashed passwords with stringent password requirements, DNA samples, and retina scans are more secure but at a cost of development and user experience. Plaintext passwords are far less secure but are cheaper to implement (but should be avoided). At end of the day, it comes down to a cost/benefit analysis of a breach. You implement security based on the value of the data being secured and its time-value.
What is the cost of someone's password getting out into the wild? What is the cost of impersonation in the given system? To the FBI computers, the cost could be enormous. To Bob's one-off five-page website, the cost could be negligible. A professional provides options to their customers and, when it comes to security, lays out the advantages and risks of any implementation. This is doubly so if the client requests something that could put them at risk because of failing to heed industry standards. If a client specifically requests two-way encryption, I would ensure you document your objections but that should not stop you from implementing in the best way you know. At the end of the day, it is the client's money. Yes, you should push for using one-way hashes but to say that is absolutely the only choice and anything else is unethical is utter nonsense.
If you are storing passwords with two-way encryption, security all comes down to key management. Windows provides mechanisms to restrict access to certificates private keys to administrative accounts and with passwords. If you are hosting on other platform's, you would need to see what options you have available on those. As others have suggested, you can use asymmetric encryption.
There is no law (neither the Data Protection Act in the UK) of which I'm aware that states specifically that passwords must be stored using one-way hashes. The only requirement in any of these laws is simply that reasonable steps are taken for security. If access to the database is restricted, even plaintext passwords can qualify legally under such a restriction.
However, this does bring to light one more aspect: legal precedence. If legal precedence suggests that you must use one-way hashes given the industry in which your system is being built, then that is entirely different. That is the ammunition you use to convince your customer. Barring that, the best suggestion to provide a reasonable risk assessment, document your objections and implement the system in the most secure way you can given customer's requirements.
将用户安全问题的答案作为加密密钥的一部分，并且不要将安全问题答案存储为纯文本（而是散列）
Make the answer to the user's security question a part of the encryption key, and don't store the security question answer as plain text (hash that instead)
我以实现多因素身份验证系统为生，因此对我来说，很自然地认为您可以重置或重建密码，同时暂时使用较少的因素来验证用户的重置/娱乐工作流程。特别是使用 OTP（一次性密码）作为一些附加因素，如果建议工作流程的时间窗口很短，则可以减轻大部分风险。我们已经为智能手机（大多数用户已经整天随身携带）实现了软件 OTP 生成器，并取得了巨大成功。在出现对商业插件的抱怨之前，我想说的是，当密码不是用于验证用户身份的唯一因素时，我们可以降低保持密码易于检索或重置的固有风险。我承认，对于站点之间的密码重用场景，情况仍然不太好，因为用户会坚持拥有原始密码，因为他/她也想打开其他站点，但您可以尝试在最安全的方式（htpps 和 html 上的谨慎外观）。
I implement multiple-factor authentication systems for a living, so for me it is natural to think that you can either reset or reconstruct the password, while temporarily using one less factor to authenticate the user for just the reset/recreation workflow. Particularly the use of OTPs (one-time passwords) as some of the additional factors, mitigates much of the risk if the time window is short for the suggested workflow. We've implemented software OTP generators for smartphones (that most users already carry with themselves all day) with great success. Before complains of a commercial plug appear, what I'm saying is that we can lower the risks inherent of keeping passwords easily retrievable or resettable when they aren't the only factor used to authenticate an user. I concede that for the password reuse among sites scenarios the situation is still not pretty, as the user will insist to have the original password because he/she wants to open up the other sites too, but you can try to deliver the reconstructed password in the safest possible way (htpps and discreet appearance on the html).
抱歉，但只要您有某种方法可以解码他们的密码，就不可能保证其安全。苦苦挣扎，如果你输了，CYA。
Sorry, but as long as you have some way to decode their password, there's no way it's going to be secure. Fight it bitterly, and if you lose, CYA.
刚刚遇到这个有趣且激烈的讨论。
但最令我惊讶的是，对以下基本问题的关注却很少：
用户年龄较大或年轻的信息并不能真正回答这个问题。但是，如果没有正确理解客户的关注点，如何做出业务决策呢？
为什么这很重要？
因为如果客户请求的真正原因是系统非常难以使用，那么也许解决确切的原因就能解决实际问题？
由于我没有这些信息，也无法与这些客户交谈，我只能猜测：这与可用性有关，见上文。
我看到的另一个问题是：
这是可能的答案。
如果您有一只名为“miaumiau”的猫，并使用她的名字作为密码，但忘记了，您是否愿意被提醒它是什么，还是希望被发送类似“#zy*RW(ew”的内容？
另一个可能的原因是用户认为想出一个新密码是一项艰巨的工作！因此，将旧密码发回给她一种将她从痛苦的工作中拯救出来的错觉，
但无论原因是什么，这就是原因。原因不是必须解决的原因。
作为用户，我想要简单的事情！
如果我登录新闻网站看报纸，我想输入 1111 作为密码并通过！ ！！
我知道这是不安全的，但我关心别人访问我的“帐户”吗？是的，
该网站是否存储我的“私人”信息？
我今天读到的新闻？
那是网站的问题，不是我的问题！
该网站是否向经过身份验证的用户显示私人信息？
那就先别表现出来！
这只是为了表明用户对问题的态度。
总而言之，我不认为这是如何“安全”存储纯文本密码的问题（我们知道这是不可能的），而是如何解决客户实际关心的问题。
Just came across this interesting and heated discussion.
What surprised me most though was, how little attention was payed to the following basic question:
The information that users are elder or young does not really answer that question. But how a business decision can be made without proper understanding customer's concern?
Now why it matters?
Because if the real cause of customers' request is the system that is painfully hard to use, then maybe addressing the exact cause would solve the actual problem?
As I don't have this information and cannot speak to those customers, I can only guess: It is about usability, see above.
Another question I have seen asked:
And here is possible answer.
If you have cat called "miaumiau" and used her name as password but forgot you did, would you prefer to be reminded what it was or rather being sent something like "#zy*RW(ew"?
Another possible reason is that the user considers it a hard work to come up with a new password! So having the old password sent back gives the illusion of saving her from that painful work again.
I am just trying to understand the reason. But whatever the reason is, it is the reason not the cause that has to be addressed.
As user, I want things simple! I don't want to work hard!
If I log in to a news site to read newspapers, I want to type 1111 as password and be through!!!
I know it is insecure but what do I care about someone getting access to my "account"? Yes, he can read the news too!
Does the site store my "private" information?
The news I read today?
Then it is the site's problem, not mine!
Does the site show private information to authenticated user?
Then don't show it in first place!
This is just to demonstrate user's attitude to the problem.
So to summarize, I don't feel it is a problem of how to "securely" store plain text passwords (which we know is impossible) but rather how to address customers actual concern.
处理丢失/忘记的密码：
任何人都不应该能够恢复密码。
如果用户忘记了密码，他们至少必须知道自己的用户名或电子邮件地址。
根据请求，在用户表中生成 GUID，并向用户的电子邮件地址发送一封电子邮件，其中包含包含该 guid 作为参数的链接。
链接后面的页面验证参数guid是否确实存在（可能带有一些超时逻辑），并要求用户输入新密码。
如果您需要热线帮助用户，请向您的拨款模型添加一些角色，并允许热线角色临时以已识别用户身份登录。记录所有此类热线登录。例如，Bugzilla 向管理员提供了这样的模拟功能。
Handling lost/forgotten passwords:
Nobody should ever be able to recover passwords.
If users forgot their passwords, they must at least know their user names or email addresses.
Upon request, generate a GUID in the Users table and sent an email containing a link containing the guid as a parameter to the user's email address.
The page behind the link verifies that the parameter guid really exists (probably with some timeout logic), and asks the user for a new password.
If you need to have hotline help users, add some roles to your grants model and allow the hotline role to temporarily login as identified user. Log all such hotline logins. For example, Bugzilla offers such an impersonation feature to admins.
在注册时通过电子邮件发送明文密码，然后将其加密并丢失怎么样？我见过很多网站都这样做，从用户的电子邮件中获取密码比将其留在服务器/计算机上更安全。
What about emailing the plaintext password upon registration, before getting it encrypted and lost? I've seen a lot of websites do it, and getting that password from the user's email is more secure than leaving it around on your server/comp.
如果您不能直接拒绝存储可恢复密码的要求，那么可以将此作为您的反论点。
我们可以正确地散列密码并为用户建立重置机制，或者我们可以从系统中删除所有个人身份信息。您可以使用电子邮件地址来设置用户首选项，但仅此而已。使用 cookie 自动获取未来访问的首选项，并在合理的时间段后丢弃数据。
密码策略中经常被忽视的一个选项是是否真的需要密码。如果您的密码策略唯一做的就是引起客户服务电话，也许您可以摆脱它。
If you can't just reject the requirement to store recoverable passwords, how about this as your counter-argument.
We can either properly hash passwords and build a reset mechanism for the users, or we can remove all personally identifiable information from the system. You can use an email address to set up user preferences, but that's about it. Use a cookie to automatically pull preferences on future visits and throw the data away after a reasonable period.
The one option that is often overlooked with password policy is whether a password is really even needed. If the only thing your password policy does is cause customer service calls, maybe you can get rid of it.
用户是否真的需要恢复（例如被告知）他们忘记的密码是什么，或者他们只是需要能够进入系统？如果他们真正想要的是登录密码，为什么不制定一个例程，将旧密码（无论它是什么）简单地更改为新密码，以便支持人员可以将其提供给丢失密码的人？
我所使用的系统正是这样做的。支持人员无法知道当前密码是什么，但可以将其重置为新值。当然，所有此类重置都应记录在某处，好的做法是向用户生成一封电子邮件，告诉他密码已重置。
另一种可能性是同时拥有两个允许访问帐户的密码。一个是用户管理的“普通”密码，另一个就像万能钥匙，只有支持人员知道并且对所有用户都相同。这样，当用户遇到问题时，支持人员可以使用主密钥登录该帐户并帮助用户将密码更改为任何内容。不用说，系统也应该记录所有使用主密钥的登录。作为一项额外措施，每当使用主密钥时，您也可以验证支持人员的凭据。
-编辑-回应关于没有主密钥的评论：我同意这很糟糕，就像我认为允许除用户之外的任何人访问用户的帐户是很糟糕的一样。如果你看一下这个问题，整个前提是客户要求一个高度受损的安全环境。
万能钥匙不一定像乍看起来那么糟糕。我曾经在一家国防工厂工作，他们认为大型计算机操作员在某些情况下需要拥有“特殊访问权限”。他们只是将特殊密码放入密封的信封中，然后将其粘贴在操作员的办公桌上。要使用密码（操作员不知道），他必须打开信封。每次换班时，值班主管的一项工作是查看信封是否已打开，如果是，则立即更改密码（由另一个部门），并将新密码放入新信封中，然后整个过程开始再来一遍。操作员将被询问为什么打开它，并且该事件将被记录下来。
虽然这不是我设计的程序，但它确实有效并且提供了出色的问责制。一切都被记录和审查，而且所有操作员都有国防部秘密许可，我们从未发生过任何滥用行为。
由于审查和监督，所有操作员都知道，如果他们滥用打开信封的特权，他们将立即被解雇，并可能受到刑事起诉。
因此，我想真正的答案是，如果一个人想把事情做好，就需要雇用他们可以信任的人，进行背景调查并实行适当的管理监督和问责制。
但话又说回来，如果这个可怜的家伙的客户有良好的管理，他们一开始就不会要求这样一个安全性受损的解决方案，现在他们会吗？
Do the users really need to recover (e.g. be told) what the password they forgot was, or do they simply need to be able to get onto the system? If what they really want is a password to logon, why not have a routine that simply changes the old password (whatever it is) to a new password that the support person can give to the person that lost his password?
I have worked with systems that do exactly this. The support person has no way of knowing what the current password is, but can reset it to a new value. Of course all such resets should be logged somewhere and good practice would be to generate an email to the user telling him that the password has been reset.
Another possibility is to have two simultaneous passwords permitting access to an account. One is the "normal" password that the user manages and the other is like a skeleton/master key that is known by the support staff only and is the same for all users. That way when a user has a problem the support person can login to the account with the master key and help the user change his password to whatever. Needless to say, all logins with the master key should be logged by the system as well. As an extra measure, whenever the master key is used you could validate the support persons credentials as well.
-EDIT- In response to the comments about not having a master key: I agree that it is bad just as I believe it is bad to allow anyone other than the user to have access to the user's account. If you look at the question, the whole premise is that the customer mandated a highly compromised security environment.
A master key need not be as bad as would first seem. I used to work at a defense plant where they perceived the need for the mainframe computer operator to have "special access" on certain occasions. They simply put the special password in a sealed envelope and taped it to the operator's desk. To use the password (which the operator did not know) he had to open the envelope. At each change of shift one of the jobs of the shift supervisor was to see if the envelope had been opened and if so immediately have the password changed (by another department) and the new password was put in a new envelope and the process started all over again. The operator would be questioned as to why he had opened it and the incident would be documented for the record.
While this is not a procedure that I would design, it did work and provided for excellent accountability. Everything was logged and reviewed, plus all the operators had DOD secret clearances and we never had any abuses.
Because of the review and oversight, all the operators knew that if they misused the privilege of opening the envelope they were subject to immediate dismissal and possible criminal prosecution.
So I guess the real answer is if one wants to do things right one hires people they can trust, do background checks and exercise proper management oversight and accountability.
But then again if this poor fellow's client had good management they wouldn't have asked for such a security comprimised solution in the first place, now would they?
根据我对这个主题的了解，我相信如果您正在构建一个带有登录/密码的网站，那么您根本不应该在服务器上看到明文密码。密码在离开客户端之前就应该进行哈希处理，甚至可能加盐。
如果您从未看到明文密码，则不会出现检索问题。
另外，我（从网上）了解到，（据称）MD5 等某些算法不再被认为是安全的。我自己无法判断，但这是值得考虑的事情。
From the little that I understand about this subject, I believe that if you are building a website with a signon/password, then you should not even see the plaintext password on your server at all. The password should be hashed, and probably salted, before it even leaves the client.
If you never see the plaintext password, then the question of retrieval doesn't arise.
Also, I gather (from the web) that (allegedly) some algorithms such as MD5 are no longer considered secure. I have no way of judging that myself, but it is something to consider.
在独立服务器上打开数据库，并为需要此功能的每个 Web 服务器提供加密的远程连接。
它不一定是关系数据库，它可以是具有 FTP 访问权限的文件系统，使用文件夹和文件而不是表和行。
如果可以的话，给网络服务器只写权限。
像普通人一样将不可检索的密码加密存储在站点的数据库中（我们称之为“pass-a”）:)
每个新用户（或密码更改）在远程数据库中存储密码的纯副本。使用服务器的 ID、用户的 ID 和“pass-a”作为此密码的复合密钥。您甚至可以对密码使用双向加密，以便晚上睡得更好。
现在，为了让某人获得密码及其上下文（站点 id + 用户 id +“pass-a”），他必须：
您可以控制密码检索服务的可访问性（仅将其公开为安全网络服务，每天仅允许一定数量的密码检索，手动执行等），甚至可以为此“特殊安全安排”收取额外费用。
密码检索数据库服务器非常隐藏，因为它不提供很多功能并且可以更好地保护（您可以严格定制权限、流程和服务）。
总而言之，你让黑客的工作变得更加困难。任何单个服务器上出现安全漏洞的可能性仍然相同，但有意义的数据（帐户和密码的匹配）将很难收集。
open a DB on a standalone server and give an encrypted remote connection to each web server that requires this feature.
it does not have to be a relational DB, it can be a file system with FTP access, using folders and files instead of tables and rows.
give the web servers write-only permissions if you can.
Store the non-retrievable encryption of the password in the site's DB (let's call it "pass-a") like normal people do :)
on each new user (or password change) store a plain copy of the password in the remote DB. use the server's id, the user's ID and "pass-a" as a composite key for this password. you can even use a bi-directional encryption on the password to sleep better at night.
now in order for someone to get both the password and it's context (site id + user id + "pass-a"), he has to:
you can control the accessibility of the password retrieval service (expose it only as a secured web service, allow only certain amount of passwords retrievals per day, do it manually, etc.), and even charge extra for this "special security arrangement".
The passwords retrieval DB server is pretty hidden as it does not serve many functions and can be better secured (you can tailor permissions, processes and services tightly).
all in all, you make the work harder for the hacker. the chance of a security breach on any single server is still the same, but meaningful data (a match of account and password) will be hard to assemble.
您可能没有考虑过的另一个选项是允许通过电子邮件进行操作。这有点麻烦，但我为一个需要系统“外部”用户查看（只读）系统某些部分的客户端实现了这一点。例如：
网站）。注册必须包含电子邮件。
记住他们的密码，他们仍然可以通过以下方式执行操作
单击常规“提交”按钮旁边的特殊“通过电子邮件向我发送许可”按钮。
正如您在评论中提到的，如果电子邮件被泄露，这将不起作用，但它确实解决了 @joachim 关于不想重置密码的评论。最终，他们将不得不使用密码重置，但他们可以在更方便的时间执行此操作，或者根据需要在管理员或朋友的帮助下执行此操作。
该解决方案的一个变化是将操作请求发送给第三方可信管理员。这对于老年人、智障人士、幼儿或其他困惑的用户来说效果最好。当然，这需要这些人有一个值得信赖的管理员来支持他们的行动。
Another option you may not have considered is allowing actions via email. It is a bit cumbersome, but I implemented this for a client that needed users "outside" their system to view (read only) certain parts of the system. For example:
website). Registration must include an email.
remember their password, they can still perform the action by
clicking on a special "email me for permission" button, right next to the regular "submit" button.
As you mentioned in the comments, this won't work if the email is compromised, but it does address @joachim 's comment about not wanting to reset the password. Eventually, they would have to use the password reset, but they could do that at a more convenient time, or with assistance of an administrator or friend, as needed.
A twist to this solution would be to send the action request to a third party trusted administrator. This would work best in cases with the elderly, mentally challenged, very young or otherwise confused users. Of course this requires a trusted administrator for these people to support their actions.
像平常一样对用户的密码进行加盐和哈希处理。当用户登录时，既允许用户的密码（加盐/散列后），也允许用户输入的内容匹配。
这允许用户输入他们的秘密密码，但也允许他们输入密码的加盐/散列版本，这是有人从数据库中读取的内容。
基本上，使加盐/散列密码也成为“纯文本”密码。
Salt-and-hash the user's password as normal. When logging the user in, allow both the user's password (after salting/hashing), but also allow what the user literally entered to match too.
This allows the user to enter their secret password, but also allows them to enter the salted/hashed version of their password, which is what someone would read from the database.
Basically, make the salted/hashed password be also a "plain-text" password.