19

我和我的同事正在就密码安全问题进行一场激烈的文明讨论。请帮助我们解决分歧。

我们中的一个人认为：

  • 除了单向散列版本之外，还可以存储使用公钥加密的密码，并且在未来合并或收购的情况下，这对于与其他身份验证系统的集成可能很有用。
  • 只有 CEO/CTO 可以访问私钥，并且只会在必要时使用。仍然会通过散列密码进行常规登录验证。
  • 我/他以前曾在以前的公司中这样做过，并且有很多网站都这样做过，并且之前曾通过财富 500 强公司的安全审计。
  • 这是一种常见且被接受的做法，即使对于金融机构也是如此，因此无需在隐私政策中明确说明这一点。
  • 像 Mint.com 这样的网站就是这样做的。

我们中的另一个人持以下观点：

  • 存储密码，即使是加密形式，也是一种不必要的安全风险，最好首先避免暴露于这种风险。
  • 如果私钥落入坏人之手，在多个站点使用相同密码的用户将面临所有登录信息被泄露的风险。
  • 这违反了我们用户的信任，如果实施这种做法，他们应该被明确告知这一点。
  • 这不是全行业的做法，也没有大牌网站（谷歌、雅虎、亚马逊等）实施这一点。Mint.com 是一个特例，因为他们需要代表您向其他网站进行身份验证。此外，他们只存储您金融机构的密码，而不是您在 Mint.com 本身的密码。
  • 这是审计中的一个危险信号。

想法？注释？您是否曾在实施这种做法的组织工作过？

4

11 回答 11

42

存储可恢复版本密码的第一种做法是完全错误的。不管大网站这样做的事实。这是错误的。他们错了。

我会自动不信任任何存储我未散列密码的网站。谁知道如果那家大公司的员工决定玩得开心会发生什么？有一个案例来自雅虎的某个人窃取并出售了用户电子邮件。如果有人用我的电子邮件和密码窃取/出售整个数据库怎么办？

您无需知道我的原始密码即可进行身份验证。即使您稍后决定拆分系统、添加新系统或与第三方集成，您仍然可以只使用密码的哈希值。

于 2009-10-22T13:14:45.060 回答
18
  • 为什么 CEO 应该比其他人更可靠/值得信赖？有一些高级政府人员丢失机密数据的例子。
  • 普通网站没有理由必须存储密码，而不是一个密码。
  • 如果将来这些私钥可以被破坏，会发生什么？如果使用的密钥是弱密钥怎么办，就像最近在 Debian 中发生的那样。

底线是：为什么一个人会冒这么大的风险而几乎没有收益。大多数公司永远不需要加密密码。

于 2009-10-22T13:20:06.780 回答
16

哈希密码

以可逆形式存储密码是不必要且有风险的。

在我看来，安全漏洞似乎比合并密码表的需要更有可能。此外，安全漏洞的成本似乎远高于实施迁移策略的成本。我相信不可逆地散列密码会更安全。

迁移策略

在公司合并的情况下，用于散列密码的原始算法可以记录在组合密码表中，并调用不同的例程来验证不同用户的密码，由该标识符确定。如果需要，此时也可以更新存储的哈希（及其标识符），因为用户的明文密码将在登录操作期间可用。这将允许逐步迁移到单个哈希算法。请注意，密码无论如何都会在一段时间后过期，因此这将是迁移所需时间的上限。

威胁

有几种方法可以攻击加密密码：

解密密钥保管人可能已损坏。他们可以解密密码并窃取它们。保管人可能会自己做这件事，或者他可能会被其他人贿赂或勒索。没有经过特殊培训的高管也特别容易受到社会工程学的影响。

也可以对用于加密的公钥进行攻击。通过用自己的公钥替换真正的公钥，任何应用程序管理员都可以收集密码。而如果只有 CEO 拥有真正的解密密钥，这在很长一段时间内都不太可能被发现。

减轻

假设这场战斗失败了，并且密码是加密的，而不是散列，我会争取几个让步：

  1. 至少，解密密钥应该需要多人合作才能恢复。像 Shamir 的秘密共享算法这样的密钥共享技术会很有用。
  2. 还需要采取措施保护加密密钥的完整性。存储在防篡改硬件令牌上或使用基于密码的 MAC 可能会有所帮助。
于 2009-10-22T15:16:19.977 回答
8

并且将来可能对与其他身份验证系统的集成有用

如果没有立即需要以可逆加密格式存储密码，请不要.

于 2009-10-22T13:20:27.460 回答
8

我在一家金融机构工作，这里的交易是：没有人应该知道用户的密码，所以到处使用的默认和实施策略是：一种使用强散列算法的散列密码。

我曾经支持这个选项：您不想麻烦处理丢失双向加密密码或有人窃取它并可以读取存储密码的情况。

如果有人丢失了他们的密码，您只需更改密码并将其提供给他们。如果一家公司需要合并，他们必须按原样保留散列密码：安全高于一切。

可以这样想：您是将家庭钥匙存放在一个带有锁的盒子中，还是您更愿意每次都随身携带？在第一种情况下：每个人都可以访问您的家庭钥匙，只要有适当的钥匙或权力来打破盒子，在第二种情况下，如果有您的钥匙，潜在的家庭破坏者应该威胁您或以某种方式将它们从您手中夺走......与密码相同，如果它们在锁定的数据库上进行哈希处理，就像没有人拥有它们的副本，因此没有人可以访问您的数据。

于 2009-10-22T13:21:30.817 回答
5

当密码被单向散列并且这不是问题时，我不得不在站点之间移动用户帐户（这可能发生在合并或收购中）。所以我不明白这个论点。

即使这两个应用程序使用不同的哈希算法，也会有一种简单的方法来处理这种情况。

于 2009-10-22T13:16:46.927 回答
2

支持存储它们的论点似乎是它可能会在合并或收购的情况下简化集成。论点的那一侧的所有其他陈述都只不过是一个理由：“这就是为什么它还不错”或“其他人正在这样做”。

在合并或收购的情况下，能够进行客户可能不希望进行的自动转换的价值是多少？您预计合并和/或收购的频率如何？为什么要按原样使用散列密码，或者要求您的客户明确同意更改？

对我来说，这似乎是一个非常薄弱的​​理由。

另一方面，当您以可恢复的形式存储密码时，它们总是存在泄露的危险。如果你不这样做，那就没有；你不能透露你不知道的东西。这是一个严重的风险。CEO/CTO 可能粗心或不诚实。加密可能存在缺陷。肯定会在某处备份私钥，并且可能会泄露出去。

简而言之，为了考虑以可恢复的形式存储密码，我需要一个很好的理由。我不认为在实施可能的业务操作可能需要或可能不需要的转换方面的潜在便利是合格的。

或者，用软件人们可能理解的形式来表达，YAGNI。

于 2009-10-22T21:47:11.130 回答
1

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...

于 2009-11-07T19:44:06.430 回答
1

我同意最安全的方法仍然是单向哈希（但当然要加盐！）。我只会在需要与其他系统集成时才使用加密。

即使您有一个需要与其他系统集成的构建系统，最好在集成之前询问您的用户该密码。这样一来，用户就会感觉自己“控制”了自己的数据。反过来，从加密密码开始，而最终用户不清楚其用途，当您在某个时间点开始集成时会引发很多问题。

因此，我肯定会使用单向哈希，除非有明确的理由（明确的开发方式和最终用户清楚！）立即需要未加密的密码。

编辑： 即使需要与其他系统集成，存储可恢复密码仍然不是最好的方法。但这当然取决于要集成的系统。

于 2009-10-22T13:17:00.297 回答
0

如果您是边缘案例，例如 mint.com，是的，请这样做。Mint 将您的密码存储到其他几个站点（您的银行、信用卡、401k 等），当您登录 Mint 时，它会转到所有其他站点，以您的身份通过脚本登录，并取回您更新的财务数据到一个易于查看的集中站点。锡箔帽安全吗？可能不是。我爱它吗？是的。

如果你不是边缘案件，主不，你不应该这样做。我为一家大型金融机构工作，这当然不是一种公认​​的做法。这可能会让我被解雇。

于 2010-03-23T15:36:44.307 回答
0

每次我与密码有关时，它们都是一种散列方式，使用不断变化的盐，即散列（userId + clearPassword）。当我们公司没有人可以访问明文密码时，我感到非常高兴。

于 2009-10-22T13:16:13.900 回答