【问题标题】:Password complexity strategies - any evidence for them?密码复杂性策略 - 有任何证据吗?
【发布时间】:2009-01-19 12:45:48
【问题描述】:

我曾多次被要求为我正在开发的软件实施密码选择规则。典型的建议包括:

  • 密码长度必须至少为 N 个字符;
  • 密码必须包含小写、大写和数字;
  • 不得重复使用最后 M 天的密码(或在 P 天内使用的密码)。

等等。

尽管对密码设置任何限制总是让我感到困扰 - 通过限制可用密码,您可以减少所有允许密码的空间大小。这不是让密码更容易猜到吗?

同样,通过让用户创建复杂且频繁更改的密码,写下密码的欲望增加,同时也降低了安全性。

是否有量化证据表明密码限制规则使系统更安全?

如果有,可以使用哪些“最安全”的密码限制策略?


编辑 Ólafur Waage 友好地指出了一个 Coding Horror article on dictionary attacks,其中包含很多有用的分析,但令我震惊的是,字典攻击可以通过简单地添加(正如 Jeff 建议的那样)大大减少身份验证尝试失败后的延迟。

考虑到这一点,有什么证据表明强制复杂密码更安全?

【问题讨论】:

    标签: security passwords


    【解决方案1】:

    有些事情一直困扰着我 对密码施加任何限制 虽然 - 通过限制可用 密码,你减少了大小 所有允许密码的空间。 这不是让密码更容易吗 你猜?

    理论上,是的。在实践中,您不允许使用的“弱”密码代表所有可能密码的一小部分,在没有限制的情况下通常不成比例地选择这些密码,并且攻击者知道首先攻击。

    同样,通过让用户创建 复杂多变 密码,写作的诱惑 他们下降增加,也减少 安全。

    正确。强迫用户每个月更改密码是一个非常非常糟糕的主意,除非在每个人都真正了解安全需求的极端高安全环境中。

    【讨论】:

      【解决方案2】:

      这类规则肯定有帮助,因为它可以阻止愚蠢的用户使用像“mypassword”这样的密码,不幸的是,这种情况经常发生。

      实际上,您是在强迫用户输入大量潜在密码。排除所有仅包含小写字母的密码集并不重要,因为剩余的密码集仍然要大几个数量级。

      但我最大的烦恼是我在主要网站上遇到的密码限制,例如

      • 无特殊字符
      • 最大长度

      为什么会有人这样做? W.H.Y.????

      【讨论】:

      • 讨厌最大密码长度。呸!
      【解决方案3】:

      Jeff 在Dictionary Attacks. 上的文章对此进行了很好的阅读

      【讨论】:

        【解决方案4】:
        1. 从不阻止用户做他们真正想做的事,除非这样做有技术限制。
        2. 您可能会因为用户做了一些愚蠢的事情(例如使用字典单词或 3 个字符的密码,或者只使用数字)而唠叨用户,但请参阅上面的 #1。
        3. 没有充分的技术理由只要求字母数字、至少一个大写字母或至少一个数字;请参见上面的 #1。

        我忘记了哪个网站有关于密码的建议:“选择一个您很容易记住但其他人很难猜到的密码。”但随后他们开始要求至少一个大写字母和一个数字。

        密码的问题在于它们无处不在,以至于没有过目不忘的人基本上不可能在不写下来的情况下真正记住它们,因此如果有人获得了这个书面列表,就会留下一个严重的安全漏洞。 -down 密码。

        我能够自己管理此问题的唯一方法是拆分我的大部分密码——我刚刚检查了我的列表,到目前为止我已经达到了 130 个! ——分为两部分,一个在所有情况下都是相同的,另一个是独特但简单的。 (对于银行账户等需要高安全性的网站,我打破了这条规则。)

        要求将“复杂性”定义为同时存在多种类型的字符,这是否会迫使人们针对不同的网站采用一组不同的约定,这使得记住相关密码变得更加困难。

        我承认网站限制允许的密码字符集的唯一原因是它需要可以在键盘上输入。如果您必须假设需要从多个国家/地区访问该帐户,那么键盘可能并不总是支持用户主键盘上的相同字符。

        这些天我必须就这个主题发表一篇博文。 :(

        【讨论】:

          【解决方案5】:

          我的旧极限定理:

          随着密码的安全性接近足够,它出现在附在计算机或显示器上的便签上的可能性接近 1。

          【讨论】:

            【解决方案6】:

            也有人可能会指出最近在 twitter 上发生的惨败,其中一个管理员的密码竟然是“幸福”,这属于字典攻击。

            【讨论】:

              【解决方案7】:

              对于这样的问题,我问自己what Bruce Schneier would do - 链接的文章是关于如何选择在典型攻击中难以猜测的密码。

              另请注意,如果您在尝试失败后添加延迟,您可能还希望在成功尝试后添加延迟,否则延迟只是攻击失败的信号,应该发起其他尝试。

              【讨论】:

              • 成功尝试后的延迟对用户来说是一个很大的烦恼,并且不会隐藏更多信息而不是没有延迟,因为还有其他方法可以测试失败。
              • 也许您担心泄露用户 ID,并假设不存在的用户 ID 登录失败不会导致延迟?我不明白为什么这是真的。
              【解决方案8】:

              虽然这不能直接回答您的问题,但我个人发现我遇到的最令人讨厌的规则是您不能重复使用以前使用的任何密码。在同一个地方工作了多年,并且必须每 2/3 个月更改一次密码,使用我一年多前选择的密码的能力似乎并不特别不安全或不安全。如果我过去使用过“安全”密码(字母数字,以防万一),肯定会在一年或 2 年后重用它们(取决于您必须多久更改一次密码),这对我来说似乎是可以接受的.这也意味着我不太可能使用“更简单”的密码,如果我想不出任何容易记住和难以猜测的密码,这可能会发生!

              【讨论】:

              • “以前的密码”限制更多的是关于入侵检测而不是密码安全。如果攻击者设法重置您的密码,那么他们可以将其设置回以前的状态,那么您将不会知道他们曾经通过重置闯入过。然后,如果他们没有将其设置回之前的值,但您设法重新进入您的帐户,如果他们知道由于入侵而之前设置的值,您仍然可以让他们访问。
              【解决方案9】:

              首先让我说最小长度、区分大小写和所需特殊字符等细节应该取决于谁有权访问以及密码允许他们做什么。如果它是发射核导弹的代码,那么它应该比登录密码更严格,才能玩付费在线版的愤怒的小鸟。

              但我有一个区分大小写的具体问题。

              对于初学者来说,用户讨厌它。人脑认为“A=a”。当然,开发人员的大脑通常并不典型。 ;-) 但是区分大小写也给开发人员带来了不便。

              第二,CapsLock键太容易误击。它在 Tab 和 Shift 键之间,但应该在 Esc 键上方。它的位置是很久以前在打字机时代建立的,打字机没有可用的替代字体。在那些日子里,它在那里很有用。

              所有密码都有风险...您正在平衡风险和易用性,是的,可用性很重要。

              我的论点: 是的,对于给定的密码长度,区分大小写更安全。但除非有人让我这样做,否则我会选择更长的最小密码长度。即使我们假设只允许使用字母和数字,每个添加的字符都会将可能的密码数量乘以 36。

              数学方面比我不那么懒惰的人可以告诉您组合数量的差异,例如最小 8 个字符的区分大小写的密码和 12 个字符的不区分大小写的密码。我想大多数用户会更喜欢后者。

              此外,并非所有应用都会向其他应用公开用户名,因此黑客可能需要找到两个字段。

              我也喜欢在密码中允许有空格,只要密码的大部分不是空格。

              在我现在正在开发的项目中,我的管理屏幕允许管理员更改密码要求,这些要求适用于所有未来的密码。他还可以强制所有用户在下次登录后随时更新密码(以符合新要求)。我这样做是因为我觉得我的东西不需要区分大小写,但管理员(可能为软件付费)可能不同意,所以我让那个人决定。

              我的银行卡的 PIN 码只有四位数。由于它只是数字,因此不区分大小写。哎呀,这是我的钱!如果您不考虑其他因素,这听起来很不安全,要不是黑客必须窃取我的卡才能获得我的钱。 (并为他拍照。)

              另外一个问题:使用 StackOverflow 并重复他们在某处文章中读到的硬性规则的开发人员。 “永远不要硬编码任何东西。” (好像这是可能的。)“所有查询都必须参数化”(如果用户没有参与查询,则不是。)等等。

              请原谅我的咆哮。 ;-) 我保证我尊重分歧。

              【讨论】:

                【解决方案10】:

                对于这个特殊的问题,我个人倾向于根据输入文本的特征给密码一个“分数”,并拒绝不符合分数的密码。

                例如:

                Contains Lower Case Letter +1
                
                Contains different Lower Case Letter +1
                
                Contains Upper Case Letter +1
                
                Contains different Upper Case Letter +1
                
                Contains Non-Alphanumeric character: +1
                
                Contains different Non-Alphanumeric character: +1
                
                Contains Number: +1
                
                Contains Non Consecutive or repeated Second Number: +1 
                
                Length less than 8: -10 
                
                Length Greater than 12: +1
                
                Contains Dictionary word: -4
                

                然后只允许得分大于 4 的密码,(并在用户通过 javascript 创建密码时提供反馈)

                【讨论】:

                  猜你喜欢
                  • 2012-07-03
                  • 2023-03-31
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 2015-04-19
                  相关资源
                  最近更新 更多