Encryption 存储加密密码

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

我们中有一个人的观点是：

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

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

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

---

想法？评论？您是否在实施此做法的组织工作过？

存储可恢复密码版本的第一种做法显然是错误的。不管大型网站是否这样做。这是错误的。他们错了

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

---

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

每次我与密码有关时，它们都是单向哈希的，并使用不断变化的salt，即哈希（userId+clearPassword）。我最高兴的是，我们公司没有人可以直接访问密码。

我不得不在站点之间移动用户帐户（在合并或收购中可能会发生这种情况），因为密码是单向散列的，这不是问题。所以我不理解这个论点

---

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

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

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

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

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

• 为什么CEO们应该比其他人更可靠/值得信赖？有一些政府高级官员丢失机密数据的例子
• 没有理由一个普通的网站必须存储一个密码，而不是一个
• 如果将来这些私钥可能会被破坏，会发生什么？如果使用的密钥是弱密钥，如

底线是：为什么一个人要冒这么大的风险，却得不到什么好处。大多数公司都不需要加密密码

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

---

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

我在一家金融机构工作，这里的交易是：任何人都不应该知道用户的密码，因此默认和实施的策略是：使用强散列算法对密码进行单向散列

我这一次支持这个选项：您不想在处理双向加密密码丢失或有人偷了密码并可以读取存储的密码的情况时遇到麻烦

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

这样想：你会把家里的钥匙放在一个有钥匙锁的盒子里，还是每次都随身携带？ 在第一种情况下：每个人都可以使用你的家庭钥匙，只要有合适的钥匙或电源可以打开盒子，在第二种情况下，如果你的钥匙可能会被家庭断路器威胁到，或者以某种方式从你手中夺走。。。密码也是一样，如果它们在锁定的数据库上散列，就像nobod一样