![]() |
1
5
理论上是的。在实践中,您不允许的“弱”密码代表了所有可能的密码中的一小部分,这些密码在没有限制的情况下被不成比例地选择,并且攻击者知道首先要攻击这些密码。
对的。强制用户每月更改密码是一个非常非常糟糕的主意,除非在极端高安全环境中,每个人都真正了解安全的需求。 |
![]() |
2
3
这类规则肯定有帮助,因为它可以阻止愚蠢的用户使用诸如“mypassword”之类的密码,不幸的是,这种情况经常发生。 因此,实际上,您正迫使用户输入一组非常大的潜在密码。排除只包含小写字母的所有密码集并不重要,因为剩余的密码集仍然是数量级更大的。 但是我的大毛病是我在主要网站上遇到的密码限制,比如
为什么会有人这么做?W.H.Y.????? |
![]() |
3
2
这是杰夫的一篇关于 Dictionary Attacks. |
![]() |
4
2
我忘记了哪个网站对密码有这样的建议:“选择一个你很容易记住,但别人很难猜到的密码。”但后来他们又要求至少一个大写字母和一个数字。 密码的问题在于,它们是如此普遍,以至于没有照片记忆的人根本不可能在不写下来的情况下真正记住它们,因此,如果有人能够访问这个写下来的密码列表,就会留下一个严重的安全漏洞。 我能为自己管理这个的唯一方法是分割我的大部分密码——我刚刚检查了我的列表,到目前为止我已经有130个了!--分为两部分,一部分在所有情况下都是相同的,另一部分是独特但简单的。(对于需要高安全性的站点,如银行帐户,我违反了此规则。) 通过要求“复杂性”(定义为多个类型的字符都存在),这就意味着它强制人们进入不同站点的一组不同的约定,这使得记住有问题的密码变得更加困难。 对于限制密码字符集的站点,我承认的唯一原因是它需要在键盘上键入。如果您必须假设帐户需要从多个国家访问,那么键盘可能不总是支持用户主键盘上的相同字符。 总有一天我会在博客上发表关于这个主题的文章。:( |
![]() |
5
2
我的旧极限定理: 当密码的安全性接近足够时,它附在计算机或监视器上的便签上的概率接近1。 |
![]() |
6
1
还有人可能会指出最近Twitter上的一次惨败,他们的一个管理员的密码被证明是“幸福”,这是一次字典攻击。 |
![]() |
7
1
对于这样的问题,我问自己 what Bruce Schneier would do -链接的文章是关于如何选择在典型攻击中很难猜测的密码。 另外请注意,如果在尝试失败后添加延迟,也可能希望在尝试成功后添加延迟,否则延迟只是攻击失败的信号,应启动其他尝试。 |
![]() |
8
0
虽然这并不能直接回答你的问题,但我个人发现了我遇到过的最具侵略性的规则,即你不能重用以前使用过的任何密码。在同一个地方工作了几年后,每2/3个月就要更改一次密码,使用我一年前选择的密码的能力似乎不会特别不安全或不安全。如果我在过去使用过“安全”密码(字母数字,如果有变化的话),那么在一年或两年后(取决于你改变密码的频率)重新使用它们对我来说是可以接受的。这也意味着我不太可能使用“更简单”的密码,如果我想不出任何容易记住和难以猜到的东西,可能会发生这种情况! |
![]() |
9
0
首先,我要说的是,诸如最小长度、区分大小写和所需的特殊字符等细节应该取决于谁有访问权限以及密码允许他们做什么。如果这是发射核导弹的密码,那么登录玩你的付费在线版《愤怒的小鸟》应该比密码更严格。 但我有一个特别的牛肉,对大小写很敏感。 首先,用户讨厌它。人脑认为“A=A”。当然,开发人员的大脑通常不是典型的。;-)但是开发人员也不方便区分大小写。 第二,带帽锁的钥匙太容易被误击。它就在tab键和shift键之间,但应该在Esc键上方。它的位置建立在很久以前的打字机时代,当时没有备用字体。那时候把它放在那里很有用。 所有密码都有风险…你在平衡风险和易用性,是的,可用性很重要。 我的论点: 是的,对于给定的密码长度,区分大小写更加安全。但除非有人让我这样做,否则我会选择更长的最小密码长度。即使我们假设只允许字母和数字,每增加一个字符,可能的密码数就会乘以36。 一个比我更懒惰数学的人可以告诉你密码组合的数量,比如至少8个字符的区分大小写的密码和12个字符的不区分大小写的密码。我认为大多数用户更喜欢后者。 此外,并非所有的应用程序都向其他人公开用户名,因此黑客可能需要找到两个字段。 我也喜欢在密码中允许空格,只要大部分密码不是空格。 在我现在开发的项目中,我的管理屏幕允许管理员更改密码要求,这些要求适用于所有未来的密码。他还可以强制所有用户在下次登录后随时更新密码(以满足新的要求)。我这样做是因为我觉得我的东西不需要区分大小写,但是管理员(可能是付钱给我买软件的)可能不同意,所以我让那个人来决定。 我银行卡的密码只有四位数。因为它只是数字,所以不区分大小写。他妈的,这是我的钱!如果你什么都不考虑,这听起来很不安全,不是因为黑客必须偷我的卡才能拿到我的钱。(并给他拍照。) 另一个问题是:开发人员来到StackOverflow,反出他们在某个地方读到的硬而快的规则。”不要硬编码任何东西。”(好像可能的话。)“所有的查询都必须参数化”(如果用户不参与查询的话就不能这样做)等等。 请原谅这咆哮。我保证我尊重分歧。 |
![]() |
10
0
就个人而言,对于这个病人问题,我倾向于根据输入文本的特征给密码一个“分数”,并拒绝不符合分数的密码。 例如:
然后只允许分数大于4的密码(并在用户通过javascript创建密码时提供反馈) |
![]() |
Michael · 某些Windows客户端上的命名管道安全问题 1 年前 |
![]() |
adamency · 是否可以从Go二进制文件的源代码中检索字符串? 1 年前 |
![]() |
AlboSimo · PayPal Api密钥安全 1 年前 |