存储加密密码

Question

我的同事和我正在进行关于密码安全的拳头打击文明讨论。请帮助我们解决分歧。

我们中的一个人认为：

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

我们其他人采取以下观点：

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

思考？评论？你是否曾在一个实施这种做法的组织工作过？

Answer 1

存储可恢复版密码的第一种做法是完全错误的。无论大型网站如何做到这一点。这是错误的。他们错了。

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

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

Answer 2

• 为什么首席执行官比其他人更可靠/更值得信赖？有一些高级政府人员丢失机密数据的例子。
• 常规网站没有理由存储密码，不是一个。
• 如果将来这些私钥被破坏会怎样？如果使用的密钥是弱密钥，如has happened just recently in Debian.
，该怎么办？

最重要的是：为什么人们会冒这么大的风险，几乎没有任何好处。大多数公司都不需要加密密码。

Answer 3

哈希密码

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

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

迁移策略

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

威胁

攻击加密密码有几种途径：

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

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

缓解

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

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

Answer 4

  

可能对集成很有用   与其他身份验证系统   未来

如果没有立即需要以可反转的加密格式存储密码，不要。

Answer 5

我在金融机构工作，这里的交易是：没有人应该知道用户的密码，因此在任何地方使用的默认和实施的策略是：单向散列密码和强散列算法。

我曾支持此选项：您不想遇到丢失双向加密密码或有人偷了它并且可以读取存储密码的情况。

如果有人丢失了密码，您只需更改密码并将其交给他们即可。 如果公司需要合并，他们必须保持散列密码的方式：安全性高于其他所有。

这样想一想：你是否将你的家庭钥匙存放在一个有钥匙锁的盒子里，或者你最好每次都把它们随身携带？ 在第一种情况下：每个人都可以使用正确的钥匙或电源来打开盒子，在第二种情况下让你的钥匙成为一个潜在的破坏者应该威胁你或者以某种方式从你那里拿走它们......与密码相同，如果它们在锁定的数据库上进行哈希处理，就像没有人拥有它们的副本一样，因此没有人可以访问您的数据。

Answer 6

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

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

Answer 7

支持存储它们的论点似乎是它可以在合并或收购的情况下简化集成。在论证的那一方的每一个其他陈述只不过是一个理由：“这就是为什么它不是那么糟糕”或“其他人正在做”。

能够进行客户在合并或收购时可能不希望完成的自动转换需要多少钱？您多久预计一次合并和/或收购？为什么使用散列密码会如此困难，或者要求您的客户明确地同意这些变更？

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

另一方面，当您以可恢复的形式存储密码时，总会存在他们将要离开的危险。如果你不这样做，就没有;你不能透露你不知道的东西。这是一个严重的风险。首席执行官/首席技术官可能不小心或不诚实。加密可能存在缺陷。肯定会在某个地方备份私钥，而这可能会出来。

简而言之，为了甚至考虑以可恢复的形式存储密码，我想要一个很好的理由。我认为实施可能或可能不需要的转换的潜在便利性不符合要求。

或者，将其置于人们可能理解的软件形式中，YAGNI。

Answer 8

我同意最安全的方法仍然是单向哈希（当然还有盐！）。当我需要与其他系统集成时，我只会求助于加密。

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

所以我肯定会采用单向散列，除非有明确的理由（明确的开发方式并且对最终用户清楚！），需要立即使用未加密的密码。

修改 即使需要与其他系统集成，存储可恢复的密码仍然不是最好的方法。但那当然取决于系统的整合。

Answer 9

首先，让CEO / CTO访问明文密码简直太愚蠢了。如果你做得对，没有必要这样做。如果一个黑客破坏了你的网站，那么是什么阻止了他攻击CEO？

这两种方法都是错误的。

将收到的密码的哈希值与存储的哈希值进行比较意味着用户在每次登录时都会发送明文密码，您的webapp中的后门将获得此密码。如果黑客没有足够的权限来建立后门，他将用他的10K GPU僵尸网络打破哈希。如果哈希不能被打破，则意味着它们会发生碰撞，这意味着你有一个弱哈希，增加了一个大小的盲目蛮力攻击。我并不夸张，这种情况每天都发生在拥有数百万用户的网站上。

让用户使用明文密码登录您的网站意味着让他们在每个网站上使用相同的密码。这就是今天99％的公共网站所做的事情，这是一种可怜的，恶意的，反进化的做法。

理想的解决方案是结合使用SSL客户端证书和服务器证书。如果您正确执行此操作，则会导致常见的MITM /网络钓鱼攻击不可能;这种攻击不能用于凭证或会话。此外，用户可以将他们的客户端证书存储在智能卡等加密硬件上，允许他们在任何计算机上登录，而不会丢失他们的凭据（尽管他们仍然容易受到会话劫持的攻击） ）。

你认为我是不合理的，但SSL客户端证书是出于某种原因而发明的......

Answer 10

每当我与密码有关时，它们都是单向散列的，使用更改的盐即散列（userId + clearPassword）。当我们公司没有人能够清楚地访问密码时，我感到非常高兴。

Answer 11

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

如果你不是一个边缘情况，不，你不应该曾这样做。我在一家大型金融机构工作，这当然 根本不是公认的做法。这可能会让我被解雇。