logo标签列表

存储加密密码

encryptionpasswordshashlinux-mint
20

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

其中之一认为：

  • 加密存储密码，并使用公钥以及单向散列版本也是可以接受的，因为这可能对于将来合并或收购时与其他身份验证系统集成可能会有用。
  • 只有CEO / CTO才能访问私钥，并且仅在必要时才会使用私钥。常规的登录验证仍将通过散列密码进行。
  • 我/他曾在以前的公司中这样做过，并且有许多站点也这样做，并且在Fortune 500公司的安全审计中幸存下来。
  • 这是常见且被接受的做法，甚至对于金融机构也是如此，因此没有必要在隐私政策中明确说明此事。
  • 像Mint.com这样的网站也这么做。

另一个人持以下观点:

  • 即使以加密形式存储密码，也是不必要的安全风险，最好避免首先暴露给这种风险。
  • 如果私钥落入错误的手中，则使用相同密码在多个网站上的用户将面临所有登录凭据被泄露的风险。
  • 这是我们对用户的信任破裂，如果实施此做法，则应明确告知用户。
  • 这不是行业普遍做法，没有大公司（Google，Yahoo，Amazon等）采取这种方式。Mint.com是一个特例，因为他们需要代表您验证其他网站。此外，他们仅存储您的金融机构密码，而不是您在Mint.com本身的密码。
  • 这是审计中的红旗。

有什么想法？评论？您是否曾在实施此做法的组织中工作过？

11个回答
42

存储可恢复版本密码的第一个实践是错误的。无论大型网站是否这样做，都是错误的。他们是错的。

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

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

4
如何判断一个网站是否以明文形式存储你的密码？你使用的一些网站可能已经这样做了。 - Eric
16
使用“忘记密码”功能来取回原始密码，通常意味着密码未经过哈希加密。 - pyrocumulus
6
您说得对，您无法确定密码。但是您可以尝试使用密码恢复功能。如果他们通过电子邮件向您发送密码，则他们很傻。如果他们向您发送一个新的自动生成的密码或重置表单的链接，则仍有希望。 - user151323
钓鱼和鲸鱼 - 后者是指有人让高层完全被华丽的言辞所蒙蔽 - 你必须拥有一位内部人员，他的凭证清白并精通欺骗...因此他们究竟如何成功获取信息可能是一项相当高超的技艺研究。 - Nicholas Jordan
Mint.com非常需要您的原始密码；他们并不是使用它对自己的系统进行身份验证，而是对远程系统进行身份验证。在这种情况下，如果他们与第三方进行集成，将会遇到问题。 - Dean J
@Dean J - Mint.com 不需要您用于登录Mint的密码。它需要来自第三方机构的密码来检查您在那里的账户。很少有服务真正需要代表您登录其他网站。 - dbkk
18
  • 为什么CEO应该比其他人更加可靠/值得信赖？高级政府官员丢失机密数据的例子是有的。
  • 普通网站没有必要存储密码，绝对没有必要。
  • 如果将来这些私钥被破解了会发生什么？如果使用的密钥是弱密钥，就像Debian最近发生的那样，会怎样呢？

归根结底，为什么要冒如此大的风险，而获益甚微甚至没有任何好处。大多数公司永远不需要加密密码。

16

哈希密码

以可逆的形式存储密码是不必要和冒险的。

在我看来，安全漏洞比合并密码表的需求更有可能出现。此外，安全漏洞的成本似乎比实施迁移策略的成本高得多。我认为将密码进行不可逆的哈希处理会更加安全。

迁移策略

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

威胁

有几种攻击加密密码的方式:

解密密钥保管人可能不正当。他们可能会解密密码并窃取它们。保管人可能会自行执行此操作，或者可能被其他人贿赂或敲诈勒索。缺乏特殊培训的高管也特别容易受到社交工程的影响。

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

缓解措施

假设已经输掉了这场战斗，并且密码是加密而不是哈希处理的，我会争取一些让步:

  1. 至少，解密密钥应要求多个人合作才能进行恢复。类似Shamir的秘密共享算法的密钥共享技术会很有用。
  2. 还需要采取措施保护加密密钥的完整性。存储在防篡改硬件令牌上，或使用基于密码的MAC可能会有所帮助。
4
关于交换公钥的观察非常有趣。 - Georg Schölly
8

并且在未来可能有助于与其他身份验证系统集成

如果没有立即需要以可逆加密格式存储密码，则不要这样做。

5
根据我的经验，因为“未来可能有用”而去做的事情中，99.9%最终都没被用到。 - caf
8

我在一家金融机构工作，这里的规定是：绝不能让任何人知道用户的密码，因此默认和实施的政策是：使用强哈希算法进行单向哈希密码。

我个人支持这种选择：您不想陷入处理情况的麻烦，比如丢失双向加密密码或有人窃取密码并能读取存储的密码。

如果有人忘记了他们的密码，你只需要更改它并将其提供给他们。 如果公司需要合并，他们必须保持哈希密码的原样：安全高于一切。

这样想吧：您会把家里的钥匙存放在一个有锁的盒子里，而这个锁有您自己的钥匙，还是您更愿意随身携带？ 在第一种情况下：只要拥有正确的钥匙或打破盒子的力量，每个人都可以访问您的家庭钥匙；在第二种情况下，如果您的钥匙被哈希锁定在数据库中，那就像没有人拥有它们一样，因此没有人可以访问您的数据。

我已经思考了很长时间（很多时间，没有太多的交易），所以在这里，还有在Erickson和David Thornly，我必须在一些非常高端的层面上工作和生存，只有在那里才会出现一些问题。如此在这里所述，如果您必须存储密钥-通常是在防篡改封条下完成的。您要做的就是在某人破解较弱的锁时更换锁-社会上充斥着毫无隐私可言的人。因此，“权威”下迫使使用较弱的解决方案<-它们可能是有效的，但在某个时候你不得不翻转汉堡。 - Nicholas Jordan
如果你只需要保护一个人的财产，那么这个问题就是成本效益的平衡：强大的锁 = 更多的保护，但如果它坏了，修理费用会比弱锁更高。至少我认为是这样的。虽然我不完全赞同这种解决方案，但这是可以理解的。 - OverLex
5
我曾经需要在不影响密码的情况下转移用户账户（如合并或收购），因此我不太理解这个观点。即使两个应用程序使用了不同的哈希算法，也有简单的方法来处理这种情况。
2
支持存储密码的论点似乎是这样，它可能会在合并或收购的情况下简化集成。该论点中的其他陈述都只是辩解：要么是“这就是为什么它不那么糟糕”，要么是“其他人都在这样做”。
能够进行自动转换，而客户可能不希望在合并或收购事件中进行转换，这值得多少钱？您预计有多少次合并和/或收购？为什么使用哈希密码会很困难，或者要求客户明确接受更改会很困难吗？
对我来说，这看起来是一个非常薄弱的理由。
另一方面，当您以可恢复的形式存储密码时，总是存在泄露的风险。如果不这样做，就没有这种风险；你不知道你不会透露。这是一个严重的风险。CEO / CTO可能会粗心或不诚实。加密中可能存在漏洞。肯定会有一个私钥的备份，它可能会泄露。
简而言之，为了考虑以可恢复的形式存储密码，我需要一个好理由。我认为在可能需要的业务操作中实现便利并不合格。
或者，用软件人可能理解的方式来表达，YAGNI。
1

首先，让CEO/CTO访问明文密码就是非常愚蠢的。如果你做得对的话，根本没有这个必要。如果黑客入侵了您的网站，他有什么阻止他攻击CEO呢？

两种方法都是错误的。

比较接收到的密码的哈希值与存储的哈希值意味着用户在每次登录时发送其明文密码，您的Web应用程序中的后门将获得此密码。如果黑客没有足够的权限来植入后门，他只会用其10K GPU botnet破解哈希。如果哈希无法被破解，则意味着它们存在冲突，这意味着您的哈希算法很弱，将盲目暴力攻击放大几倍。我并不夸张，这种情况每天都在发生，在拥有数百万用户的网站上。

让用户使用明文密码登录您的网站意味着让他们在每个网站上都使用相同的密码。这是今天99%的公共网站所采用的可悲、恶意、反进化的做法。

理想的解决方案是使用SSL客户端证书和服务器证书的组合。如果您正确地执行此操作，它将使常见的MITM /网络钓鱼攻击变得不可能；这样的攻击不能用于凭据或会话。此外，用户可以将其客户端证书存储在加密硬件（如智能卡）上，使他们能够在任何计算机上登录，而无需担心失去自己的凭据（尽管他们仍然容易受到会话劫持的威胁）。

你可能认为我要求过高了，但是SSL客户端证书的发明是有原因的...

1

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

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

因此，除非有明确的原因（从开发和最终用户的角度都很明确！）需要立即使用未加密的密码，否则我肯定会选择单向哈希。

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

0

如果你像mint.com这样是个边缘案例，那么可以考虑使用。Mint会存储你在其他几个网站（银行、信用卡、401k等）上的密码，当你登录Mint时，它会通过脚本登录到所有这些网站，并将你的最新财务数据汇总到一个易于查看的中央站点。它安全吗？可能不是。我喜欢它吗？是的。

如果你不是边缘案例，千万不要这样做。我在一家大型金融机构工作，这绝对不是被接受的做法。这可能会让我失业。

即使是Mint.com也没有存储您用于登录Mint本身的密码的任何理由，只会存储第三方网站的凭据。 - dbkk
@dbkk，你说得完全正确，如果我有所暗示，那我很抱歉。他们需要存储你委托给他们的第三方密码。我发现他们的服务对我非常有用，所以在我的情况下是值得的。 - Dean J
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接