存储加密密码
我和我的同事正在就密码安全问题进行拳头文明讨论。请帮助我们解决分歧。
我们中的一个人认为：
- 除了单向哈希版本之外，存储使用公钥加密的密码是可以的，并且可能有助于将来在合并或收购时与其他身份验证系统集成。
- 只有首席执行官/首席技术官才能访问私钥，并且只有在必要时才会使用私钥。常规登录验证仍将通过散列密码进行。
- 我/他以前在以前的公司做过这样的事情，而且有很多网站都这样做，并且之前已经通过了财富 500 强公司的安全审核。
- 这是一种常见且可接受的做法，即使对于金融机构也是如此，因此无需在隐私政策中明确说明这一点。
- Mint.com 等网站就是这样做的。
我们中的另一个人持以下观点：
- 存储密码，即使以加密形式，也是一种不必要的安全风险，最好首先避免暴露于这种风险。
- 如果私钥落入坏人之手，在多个站点使用相同密码的用户将面临所有登录信息被泄露的风险。
- 这违反了我们用户的信任，如果实施这种做法，应明确告知他们。
- 这不是全行业的做法，也没有知名网站（谷歌、雅虎、亚马逊等）实施这一做法。 Mint.com 是一个特例，因为他们需要代表您向其他网站进行身份验证。此外，他们只存储您金融机构的密码，而不存储您 Mint.com 本身的密码。
- 这是审计中的一个危险信号。
想法？评论？您是否曾在实施这种做法的组织工作过？
My coworker and I are having a fist-fight civilized discussion over password security. Please help us resolve our differences.
One of us takes the viewpoint that:
- Storing passwords encrypted using a public key in addition to a one-way hashed version is OK and might be useful for integration with other authentication systems in the future in case of a merger or acquisition.
- Only the CEO/CTO would have access to the private key, and it would only be used when necessary. Regular login validation would still occur via the hashed password.
- I have/he has done this before in previous companies and there are many sites out there that do this and have survived security audits from Fortune 500 companies before.
- This is a common, and accepted practice, even for financial institutions, thus there is no need to explicitly state this in the privacy policy.
- Sites like Mint.com do this.
The other one of us takes the following viewpoint:
- Storing passwords, even in encrypted form, is an unnecessary security risk and it's better to avoid exposure to this risk in the first place.
- If the private key falls into the wrong hands, users that use the same password across multiple sites would risk having all of their logins compromised.
- This is a breach of trust of our users, and if this practice is implemented, they should be explicitly informed of this.
- This is not an industry-wide practice and no big name sites (Google, Yahoo, Amazon, etc.) implement this. Mint.com is a special case because they need to authenticate with other sites on your behalf. Additionally, they only store the passwords to your financial institutions, not your password to Mint.com itself.
- This is a red flag in audits.
Thoughts? Comments? Have you worked at an organization that implemented this practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
存储可恢复版本的密码的第一种做法是完全错误的。不管大网站这样做的事实如何。这是错误的。他们错了。
我自然而然地不信任任何存储我的未散列密码的网站。谁知道如果那家大公司的员工决定玩得开心会发生什么？曾经有一个案例，雅虎的某个人窃取并出售了用户的电子邮件。如果有人用我的电子邮件和密码窃取/出售整个数据库怎么办？
您无需知道我的原始密码即可执行身份验证。即使您稍后决定拆分系统、添加新系统或与第三方集成，您仍然只需使用密码的哈希值即可。
The first practice of storing recoverable version of passwords is plain wrong. Regardless of the fact that big sites do this. It is wrong. They are wrong.
I automatically distrust any site that stores my password unhashed. Who knows what would happen if the employees of that big company decide to have fun? There was a case some guy from Yahoo stole and sold user emails. What if someone steals/sells the whole database with my emails and passwords?
There is no need whatsoever for you to know my original password to perform authentication. Even if you decide later to split the system, add a new one or integrate with a third party, you still will be fine with just a hash of the password.
底线是：为什么人们要冒如此大的风险却几乎没有任何好处。大多数公司永远不需要加密密码。
The bottom line is: Why would one take such great risks for little to no benefit. Most companies aren't ever going to need an encrypted password.
散列密码
以可逆形式存储密码是不必要的，而且存在风险。
在我看来，安全漏洞似乎比合并密码表的需要更有可能。此外，安全漏洞的成本似乎远远高于实施迁移策略的成本。我相信不可逆地散列密码会更安全。
迁移策略
在公司合并的情况下，可以在组合密码表中记录用于散列密码的原始算法，并调用不同的例程来验证由该标识符确定的不同用户的密码。如果需要，存储的散列（及其标识符）也可以在此时更新，因为用户的明文密码在登录操作期间将可用。这将允许逐步迁移到单一哈希算法。请注意，密码无论如何都会在一段时间后过期，因此这将是迁移所需时间的上限。
威胁
有多种途径可以攻击加密密码：
解密密钥保管人可能已损坏。他们可以解密密码并窃取它们。保管人可能会自己这样做，也可能会受到其他人的贿赂或勒索。未经特殊培训的高管也特别容易受到社会工程的影响。
还可以对用于加密的公钥进行攻击。通过用自己的公钥替换真实的公钥，任何应用程序管理员都可以收集密码。而如果只有CEO拥有真正的解密密钥，这在很长一段时间内都不太可能被发现。
缓解措施
假设这场战斗失败了，并且密码被加密而不是散列，我会继续争取一些让步：
Hash Passwords
Storing passwords in a reversible form is unnecessary and risky.
In my opinion, a security breach seems much more likely than the need to merge password tables. Furthermore, the cost of a security breach seems far higher than the cost of implementing a migration strategy. I believe it would be much safer to hash passwords irreversibly.
Migration Strategy
In case of a company merger, the original algorithm used to hash passwords can be noted in a combined password table, and different routines called to verify the passwords of different users, determined by this identifier. If desired, the stored hash (and its identifier) can be updated at this time too, since the user's clear-text password will be available during the login operation. This would allow a gradual migration to a single hash algorithm. Note that passwords should expire after some time anyway, so this would be upper bound on the time migration would require.
Threats
There are a couple of avenues to attack encrypted passwords:
The decryption key custodian could be corrupt. They could decrypt the passwords and steal them. A custodian might do this on his own, or he could be bribed or blackmailed by someone else. An executive without special training is especially susceptible to social engineering too.
An attack can also be made on the public key used for encryption. By substituting the real public key with one of their own, any of the application administrators would be able to collect passwords. And if only the CEO has the real decryption key, this is unlikely to be discovered for a long time.
Mitigation
Supposing this battle is lost, and the passwords are encrypted, rather than hashed, I'd fight on for a couple of concessions:
如果没有立即需要以可逆加密格式存储密码，不要。
If there is no immediate need to store the password in a reversable encrypted format, don't.
我在一家金融机构工作，这里的协议是：任何人都不应该知道用户的密码，因此到处使用的默认和实施的策略是：使用强大的散列算法对密码进行单向散列。
我曾经支持这个选项：您不想陷入处理丢失双向加密密码或有人窃取它并可以读取存储的密码的情况的麻烦。
如果有人丢失了密码，您只需更改密码并将其提供给他们即可。
如果一家公司需要合并，他们必须保持哈希密码的原样：安全高于一切。
这样想一下：您会将家庭钥匙存放在一个有锁和您拥有的钥匙的盒子里，还是您更愿意每次都随身携带它们？
在第一种情况下：每个人都可以访问您的家庭钥匙，只要有适当的钥匙或力量来破坏盒子，在第二种情况下，为了获得您的钥匙，潜在的家庭破坏者应该威胁您或以某种方式从您手中夺走它们......与密码相同，如果它们在锁定的数据库上进行哈希处理，就好像没有人拥有它们的副本，因此没有人可以访问您的数据。
I'm working in a financial institution and here the deal is: no one should ever know user's password, so the default and implemented policy used everywhere is: one way hashed passwords with a strong hashing algorithm.
I for once stand in favor of this option: you do not want to go into the trouble of handling the situation where you have lost your two-way encryption password or someone stole it and could read the stored passwords.
If somebody loses their password you just change it and give it to them.
If a company needs to merge, they HAVE to keep hashed passwords the way they are: security is above everything else.
Think about it this way: would you store your home keys in a box that has a lock with a key you have, or would you better prefer to keep them with you everytime?
In the first case: everybody could access your home keys, given the proper key or power to break the box, in the second case to have your keys a potential home-breaker should threaten you or take them from you in some way... same with passwords, if they are hashed on a locked DB it is like nobody has a copy of them, therefore no one can access your data.
当密码经过单向散列处理并且这不是问题时，我不得不在站点之间移动用户帐户（这可能发生在合并或收购中）。所以我不太理解这个说法。
即使两个应用程序使用不同的哈希算法，也会有一种简单的方法来处理这种情况。
I have had to move user accounts between sites (as might happen in a merger or acquisition) when the passwords were one-way hashed and it was not a problem. So I do not understand this argument.
Even if the two applications used different hashing algorithms, there will be a simple way to handle the situation.
支持存储它们的论点似乎是，它可能会简化合并或收购情况下的集成。争论这一方的所有其他陈述都只不过是一个理由：要么“这就是为什么它没那么糟糕”，要么“其他人也在这样做”。
能够执行客户在合并或收购时可能不希望执行的自动转换值多少钱？您预计合并和/或收购的频率是多少？为什么按原样使用散列密码或要求客户明确同意更改会那么困难？
对我来说，这似乎是一个很薄弱的理由。
另一方面，当您以可恢复的形式存储密码时，总是存在密码被泄露的危险。如果你不这样做，那就没有；你不能透露你不知道的事情。这是一个严重的风险。 CEO/CTO 可能粗心或不诚实。加密可能存在缺陷。私钥肯定会在某个地方有备份，而且可能会泄露。
简而言之，为了考虑以可恢复的形式存储密码，我需要一个充分的理由。我认为实施可能的业务操作可能需要或不需要的转换的潜在便利性不合格。
或者，用软件人员可能理解的形式来说，YAGNI。
The argument in favor of storing them seems to be that it might simplify integration in the case of a merger or acquisition. Every other statement in that side of the argument is no more than a justification: either "this is why it's not so bad" or "other people are doing it".
How much is it worth to be able to do automatic conversions that a client may not want done in event of merger or acquisition? How often do you anticipate mergers and/or acquisitions? Why would it be all that difficult to use the hashed passwords as they are, or to ask your customers to explicitly go along with the changes?
It looks like a very thin reason to me.
On the other side, when you store passwords in recoverable form there's always a danger that they'll get out. If you don't, there isn't; you can't reveal what you don't know. This is a serious risk. The CEO/CTO might be careless or dishonest. There might be a flaw in the encryption. There would certainly be a backup of the private key somewhere, and that could get out.
In short, in order to even consider storing passwords in recoverable form, I'd want a good reason. I don't think potential convenience in implementing a conversion that might or might not be required by a possible business maneuver qualifies.
Or, to put it in a form that software people might understand, YAGNI.
我同意最安全的方法仍然是单向哈希（但当然要加盐！）。只有当我需要与其他系统集成时，我才会采用加密。
即使您拥有一个需要与其他系统集成的内置系统，最好在集成之前询问您的用户该密码。这样，用户就会感觉“掌控”自己的数据。相反，从加密密码开始，而最终用户不清楚其用途，当您在某个时间点开始集成时，会引发很多问题。
因此，我肯定会选择单向哈希，除非有明确的原因（明确的开发方向和最终用户清楚！）立即需要未加密的密码。
编辑：
即使需要与其他系统集成，存储可恢复的密码仍然不是最好的方法。但这当然取决于要集成的系统。
I would agree that the safest way remains the one-way hash (but with a salt of course!). I'd only resort to encryption when I'd need to for integrating with other systems.
Even when you have a built system that is going to need integration with other systems, it's best to ask your users for that password before integrating. That way the user feels 'in control' of his own data. The other way around, starting with encrypted passwords while the use is not clear to the end-user, will raise a lot of questions when you start integrating at some point in time.
So I will definitely go with one-way hash, unless there is a clear reason (clear development-wise and clear to the end-user!) that the unencrypted password is immediately needed.
edit:
Even when integration with other systems is needed, storing recoverable passwords still isn't the best way. But that of course, depends on the system to integrate with.
好吧，首先，让 CEO/CTO 访问纯文本密码是非常愚蠢的。如果你做事正确，就没有必要这样做。如果黑客破坏了您的网站，什么才能阻止他接下来攻击首席执行官？
这两种方法都是错误的。
将收到的密码的哈希值与存储的哈希值进行比较意味着用户在每次登录时发送其明文密码，您的网络应用程序中的后门将获取此密码。如果黑客没有足够的权限来植入后门，他只会用他的 10K GPU 僵尸网络来破坏哈希值。如果哈希值无法被破解，则意味着它们存在冲突，这意味着您的哈希值较弱，从而大大增强了盲目的暴力攻击。我并不夸张，这种情况每天都在拥有数百万用户的网站上发生。
让用户使用明文密码登录您的网站意味着让他们在每个网站上使用相同的密码。这就是当今 99% 的公共网站所做的事情，这是一种可悲的、恶意的、反进化的做法。
理想的解决方案是结合使用 SSL 客户端证书和服务器证书。如果您正确执行此操作，则常见的中间人/网络钓鱼攻击不可能；此类攻击不能针对凭证或会话。此外，用户可以将其客户端证书存储在智能卡等加密硬件上，从而允许他们登录任何计算机，而不会面临丢失凭据的风险（尽管他们仍然容易受到会话劫持） ）。
你可能会觉得我无理取闹，但 SSL 客户端证书的发明是有原因的......
Okay first of all, giving the CEO/CTO access to plaintext passwords is just plain stupid. If you are doing things right, there is no need for this. If a hacker break your site, what's stopping him from attacking the CEO next?
Both methods are wrong.
Comparing the hash of a received password against a stored hash means the user sends his plaintext password on every login, a backdoor in your webapp will obtain this. If the hacker does not have sufficient privileges to plant a backdoor, he will just break the hashes with his 10K GPU botnet. If the hashes cannot be broken, it means they have collisions, which means you have a weak hash, augmenting a blind brute force attack by magnitudes. I am not exaggerating, this happens every day, on sites with millions of users.
Letting users use plaintext passwords to login to your site means letting them user the same password on every site. This is what 99% of all public sites do today, it is a pathetic, malicious, anti-evolutionary practice.
The ideal solution is to use a combination of both SSL client certificates and server certificates. If you do this correctly, it will render the common MITM/Phishing attack impossible; an attack of such could not be used against the credentials OR the session. Furthermore, users are able to store their client certificates on cryptographic hardware such as smart cards, allowing them to login on any computer without the risk of losing their credentials (although they'd still be vulnerable to session hijacking).
You make think I'm being unreasonable, but SSL client certificates were invented for a reason...
每次我与密码有关时，它们都会以一种方式进行哈希处理，即使用不断变化的盐，即哈希值（userId +clearPassword）。当我们公司没有人能够以明文方式访问密码时，我感到非常高兴。
Every time I have anything to do with passwords they are one way hashed, with a changing salt i.e. hash(userId + clearPassword). I am most happy when no one at our company can access passwords in the clear.
如果你是边缘案例，比如 mint.com，是的，就这么做吧。 Mint 将您的密码存储到其他几个站点（您的银行、信用卡、401k 等），当您登录 Mint 时，它会转到所有其他站点，以您的身份通过脚本登录，并提取您更新的财务数据进入一个易于查看的集中站点。锡箔帽安全吗？可能不会。我喜欢它吗？是的。
如果您不是边缘案例，上帝啊，您不应该永远这样做。我在一家大型金融机构工作，这当然根本不是一种可接受的做法。这可能会让我被解雇。
If you're a fringe case, like mint.com, yes, do it. Mint stores your passwords to several other sites (your bank, credit card, 401k, etc), and when you login to Mint, it goes to all of those other sites, logs in via script as you, and pulls back your updated financial data into one easy-to-see centralized site. Is it tinfoil-hat secure? Probably not. Do I love it? Yes.
If you're not a fringe case, lord no, you shouldn't ever be doing this. I work for a large financial institution, and this is certainly not at all an accepted practice. This would probably get me fired.