我一直想知道为什么这么多的网站对密码长度有严格的限制(恰好8个字符,最多8个字符,等等)。这些通常是我真正关心其安全性的银行或其他站点。

我知道大多数人会选择“ password”和“ 123456”之类的短密码,但是是否有技术上的理由强制这样做?使用1Password这样的应用程序,几乎我所有的密码都是类似fx9@#^L;UyC4@mE3<P]uzt或其他随机生成的长字符串,这些字符串不太可能让人猜到。


网站对密码长度实施严格限制是否有特定原因? (更像是8或10,我知道为什么100000000可能是个问题...)?


评论

我必须补充一点,安全密码也可以是“正确的电池钉”。没有任何理由,我只能告诉您联系仍执行此规则的网站。

@ s4uadmin不,“ correcthorsebatterystaple”并不安全,因为它广为人知,并且很可能存在于字典攻击中。另外,尝试在DropBox上使用此密码吗?

@AlvinWong我相信s4uadmin提供了一个著名的示例,而不是有人实际上选择“正确的电池主钉”作为自己的文字密码的建议。

@AlvinWong,来自Dropbox的javascript源代码,这是一个东方鸡蛋:if(pwd =='correcthorsebatterystaple'|| pwd =='Tr0ub4dour&3'|| pwd =='Tr0ub4dor&3'){// Easteregg [...]

别忘了,黑客现在将“正确的马力钉书钉”作为其蛮力清单上的第一项:)

#1 楼

取五只黑猩猩。将它们放在一个大笼子里。从笼子的顶部悬挂一些香蕉。为黑猩猩提供梯子。但是,还向香蕉添加了一个接近检测器,因此,当黑猩猩靠近香蕉时,就会触发水管,并将整个笼子完全浸透。

很快,黑猩猩就会知道香蕉和最好忽略梯子。

现在,移走一只黑猩猩,然后换上一只新的黑猩猩。那只黑猩猩对软管一无所知。他看到了香蕉,注意到了梯子,并且由于他是一个灵巧的灵长类动物,他设想自己会踩在梯子上到达香蕉。然后,他巧妙地抓住了梯子……而另外四只黑猩猩则向他扑来,并正直击败了他。他很快学会了不理会梯子。

然后,移开另一只黑猩猩,并换上一只新的黑猩猩。该场景再次发生;当他抓住梯子时,就被另外四只黑猩猩伤了,是的,包括以前的“新鲜”黑猩猩。他综合了“不要触摸梯子”的概念。

反复进行。完成一些操作后,您有五只黑猩猩准备打孔任何敢于碰梯子的黑猩猩-而且他们都不知道为什么。


最初,某个地方的某个开发人员在上个世纪的旧Unix系统上工作,该系统使用了旧的基于DES的“ crypt”,实际上是从DES分组密码派生的密码哈希函数。在该散列函数中,仅使用密码的前八个字符(也仅使用每个字符的低7位)。后续字符将被忽略。那就是香蕉。

互联网上到处都是黑猩猩。

评论


哦,我以为熊们正在接管互联网...

–Rory Alsop♦
2013年3月30日21:54

我也喜欢这个故事。永远不要让事实妨碍良好的道德故事:skeptics.stackexchange.com/questions/6828/…:)

– KutuluMike
13年3月31日在0:08

在做出此答案期间,几只黑猩猩受到了伤害。 (顺便说一句,喜欢这个解释!)

–洛伦佐·冯·马特宏峰
13年3月31日0:28



有没有证据表明这确实是原因?例如。有没有人问过设计密码最大长度的系统的人为什么这样做呢?

– LarsH
13年3月31日在1:56

@LarsH:有一天,我问了一个黑猩猩(电话上用于重置密码的2级技术支持),为什么密码必须是6位数字且不再是(无字母),由系统生成并通过未跟踪的纸质邮件发送。答案是“我们是银行,不能承担任何安全风险”。放弃香蕉。

– PPC
13年4月2日在15:59

#2 楼

这些限制通常是由于各种原因而设置的:

与不支持长密码的旧系统的交互。
公约(即“我们一直这样做”)
天真或无知。

就安全性而言,无需限制密码长度。无论如何,应使用诸如bcrypt之类的密钥派生函数(KDF)对它们进行哈希处理。为了提高性能,可能需要对密码长度设置一个非常大的限制(例如512个字符),以防止有人向您发送1MB密码并在计算哈希值的同时对您的服务器进行10秒钟的DoS操作。

评论


值得一提的是,良好的密码哈希函数不会受到密码长度的很大影响。对于与HMAC一起使用的PBKDF2,密码是HMAC密钥,因此,通过应用HMAC,首先将其规范化为一个不超过一个内部块(通常为64个字节)的值。由于密码非常长,要获得10秒的额外CPU工作时间,该密码应该大约为1.5 GB,而不仅仅是兆字节。

–托马斯·波宁(Thomas Pornin)
13年3月30日在21:59

是的,可能会比CPU早得多地分配带宽

–半比特
13年3月30日在22:54

@Kaz没有人说过。

–多项式
13年3月31日在1:46

密码短语中的每个字符都会对哈希值产生一定的熵。但是,如果散列最终是某个N位字符串,那么如果密码短语具有大于N位的熵,则它是多余的。让我们做一个荒谬的例子。假设哈希为16位宽,您使用的是一个1兆字节的密码。破解者很可能会发现一些很短的字符组合,它们会产生相同的哈希,因此可以代替您的一兆密码。相对于哈希函数的强度,肯定会减少超出某些密码长度的收益。

–卡兹
13年3月31日在18:12

@PPC密码质量!=密码熵。熵是纯粹的统计量度。

–多项式
13年4月2日在18:53

#3 楼


如果它们以纯文本或加密的纯文本存储,则可能是可以存储在数据库中的最大值。另一方面,应该尽可能远离这些站点
,以避免DOS攻击。通常,如果它们有很高的限制(例如512或1024字节)
,以遵守对IT安全性一无所知的人实际上制定的法规
由于传统原因,如Tom Leek指出

顺便说一句。这是具有最大密码长度的排名较高的站点的(历史)列表:

http://web.archive.org/web/20130907182806/https://defuse.ca/password-policy- hall-of-shame.htm

评论


基于此:密码越长,散列的代价就越高。这是一个可怕的论据,因为用PBKDF2哈希128个字符的成本仅比哈希8个字符的成本低,从而使任何DoS风险都无效(仅从pw长度开始)。更糟糕的是将密码存储为纯文本格式,尽管这可能会引起存储问题。我全都限制密码长度,但我认为没有理由将密码长度限制在一百以下。

–亚当·卡兹(Adam Katz)
16-2-25在22:55



顺便说一句,值得指出的是,所有密码的长度都是有限的。即使表单允许无限制的字符,Web服务器也几乎可以设置为具有最大POST负载大小。即使未将Web服务器配置为拒绝请求,最终您的浏览器和/或PC也会用尽内存来存储密码。当然,大多数普通人都不会尝试输入超长密码,但是-特别是对于像银行这样的高价值目标而言-值得他一筹莫展的开发人员应该能够告诉您该限制是什么以及何时发生限制它受到打击。

–GrandOpener
17年12月23日在6:24

#4 楼

我在荷兰最大的网上商店之一Bol.com上问了这个问题。他们的回应是防止充斥有关忘记密码的支持电子邮件。然后他们好奇地忽略了我对密码重置功能的询问,该功能只是在您忘记密码后通过电子邮件发送给您重置密码。

我认为这很可能是管理团队的决定。或者,也可能是他们不对密码进行哈希处理,并使用此密码来防止其数据库被淹没(即使您可以使用更长的用户名,所以这似乎不太可能)。他们也没有回答有关是否对密码进行哈希处理的问题(您会认为,如果一切正常,将没有理由不予答复)。

评论


我的超市(网上购物)也以同样的理由小跑。完全荒谬,由没有安全概念的人清楚地实施。

–基本
15年7月17日在1:47

看起来其中一些黑猩猩在Bol.com上找到了工作:-)

– Paul Pladijs
16年6月30日在12:54

哈哈,与德国Telekom公司基本相同:D

–菲涅耳
18年8月20日在14:19

#5 楼

我会尝试减少客户服务相关的问题。

密码越大越复杂,客户输入无效密码,被锁定然后联系客户服务人员占用该时间的可能性就越大。

令人惊讶的是,有多少人无法准确键入普通的弱密码,更不用说密码长了几个字符或者必须输入一个额外的字符或输入2个字符才能获得复杂性。

可能是OT,但是长密码并不一定是真正的安全措施,因为如今密码是在相当普遍的基础上被盗的。

失败的登录尝试和跟踪与正常登录使用情况的地理距离是更准确的指标。如果属于已知的骇客入侵/攻击简介国家/地区的IP登录到美国银行,并且以前从未在该位置使用过该登录名..... SF /银行通常具有非常低的失败登录尝试次数,从而导致整个系统范围的锁定。诸如SF之类的工具甚至可以进行单独的IP分配,这意味着您不能在未经授权的情况下从新IP地址登录。

评论


这可能是这种想法,但是恕我直言,这种思维方式存在严重缺陷。为什么因为某些用户更喜欢短密码,为什么选择使用长而安全的密码呢?密码重置通常不涉及客户服务干预。另外,如果密码可以“直接被盗”(例如,密码以纯文本形式存储),那么您这样做是完全错误的。

–安东尼
13年3月31日在16:42



根据我的经验,没有正确输入/记住密码的客户确实会通过电子邮件和电话捆绑客户支持。通过密码被盗,我指的是数以百万计的带有特洛伊木马程序/密钥侦听器以及大量网络钓鱼尝试的僵化计算机。赛门铁克几年前就发布了#个被盗密码。

– MDR
13年3月31日在20:54



好的答案,但是为了取悦“即使长密码的人也会发明长密码,然后忘记密码并打电话而不是使用密码重置”的用户,您将“使用长密码的用户拒之门外”在密码管理器中”。愚弄一个无休止,毫无意义的任务,所以最好教育健忘的团队并培养明智的团队。这就是恕我直言,为什么较小的密码长度限制是一个严重缺陷的想法。

–安东尼
13年4月1日在13:04



@SaiManojKumarYadlapati:如果可以强制使用密码,则系统存在缺陷。此外,如果密码可以通过键盘记录器/僵化计算机窃取(这是非常有规律的),并且可以访问“关键”信息,则这也表示系统存在缺陷。

– MDR
13年4月1日在17:47



@安东尼:你做得很好,但我认为这是理论上的观点。我知道我们公司为“客户关系”工作了几个人。我知道,客户致电或发送电子邮件给我们的与业务特定问题无关的2大原因均与登录有关。第一个原因是“他们使用错误的电子邮件地址注册了”第二个原因是他们无法输入密码/忘记了密码。虽然我100%同意您的说法,但我的专业经验(在任何大型银行中都没有)表明,此问题可能使企业主蒙受损失。

– MDR
13年4月1日在17:52



#6 楼

“与不支持长密码的旧系统进行交互。”如上所述,这是我工作的一家公司必须强制设置最大密码长度的原因。
由于存在一个变体,“一个团体的移动速度与其最慢的成员一样快”,因此使用了多个系统所有用户必须有权使用相同的登录凭据,这意味着必须将这些系统之一的任何限制应用于所有帐户。

因此,如果一个应用程序不喜欢^,则所有系统的所有密码都不能使用^。如果一个程序不喜欢密码> 8个字符,那么所有帐户的密码都必须<9个字符。因此,在像BigCo这样工作的复杂环境中,这可能涉及十几个或十二个不同的软件。 LCD是每个人都能得到的。

他们也使用IE6。

评论


我大笑你的最后一句话。

– Gigazelle
13年3月31日在7:02

成员较慢的团队真的需要背后的狮子来保持动力。

– Jeff Ferland♦
13年3月31日在8:37

IE6安全性在后面会算是狮子吗?

–显示名称
2015年10月1日15:09

@SargeBorsch更笼统的陈述认为,对于x,y的某些值,它确实算作y中的x。

– Tobia Tesan
16 Jul 29'11:42



@TobiaTesan我爱你的评论

–陆even
18年1月4日在9:30

#7 楼

我想解决的另一种可能性是,当以明文形式保存密码时,密码有时会受到用于保存密码的字段长度的限制。如果您的字段是VARCHAR(32),则最多可以保存32个字符。

但是,这意味着更糟的事情-密码以纯文本格式保存。这就是为什么我们在plaintextoffenders.com上将这类违法行为作为(轻量级)证据接受的原因。

评论


这个。如果它们对密码进行哈希处理,则它们的长度都是相同的。因此,如果一个站点说“最大长度X个字符”,我认为它们要么是1)存储纯文本,要么是2)使用无意义的验证。 #1似乎更有可能。

–内森·朗(Nathan Long)
13年4月2日在13:42



电子邮件证明中是否显示密码以纯文本形式存储?发送电子邮件后,他们不能散列并存储它吗?并不是说它们是当然的,而且我认为在电子邮件中发送密码可能是不安全的,这是出于另一个原因,但至少看起来似乎不是确定的证据。

–Vadoff
17 Mar 11 '17 at 0:08



电子邮件从定义上说是一种不安全的媒介,因此不明智。更不用说人们可能永远也不会删除电子邮件,并且有权访问其邮箱的任何人都可以查找“ password”一词并立即访问其帐户。

–奥马尔·范·克洛滕
17年3月11日在13:59

#8 楼

密码长度限制是合理的,只要该限制仍允许使用强密码。例如,限制不得少于64个字符。设置密码时的声音限制比静默截断密码要好得多。

如果应用程序最终以128位(希望是盐腌和键拉伸)的哈希存储密码,则允许密码没有任何好处超过约64个字符。例如,对于带有5个字符的单词的Diceware密码短语,其间有空格,则64个字符的密码短语允许10个单词,其熵大于128位。或通过密码字段注入的缓冲区溢出攻击-授予您应该使用标准方法来防止这些攻击:始终将绑定参数与SQL结合使用(相对于字符串操作来构造查询),并且始终正确地对字符串进行边界检查(可能使用安全的方法)具有内置保护功能的编程语言或安全库)。您需要担心所有用户输入上的这些攻击。这不是密码字段唯一的,因此通过最大密码大小获得的保护可能可以忽略。

限制也可能有相切的原因。向用户提供带有PIN(个人识别码)的ATM卡的银行可以选择强制用户使用4到10位数之间的PIN。在实践中,允许用户设置和使用50位PIN的安全性可能比说8位PIN的安全性提高小-当攻击者同时需要用户的ATM卡(尚未被盗)时,请使用受监控的自动柜员机,并在4次错误尝试后被锁定。 50位数的PIN可能会给您的银行带来更大的人工成本,因为它会更频繁地被错误地忘记/输入-可能会触发员工进行调查(例如,检查ATM视频并与以前的成功交易进行比较)或员工引导客户通过一些必定冗长的密码重置机制(例如,重置机制必须昂贵,因此它并不是最薄弱的环节)。这整个过程可能会导致不良的客户用户体验,而银行希望避免这种情况。

评论


Steamstore的上限为63个字符。我想避免长/整数溢出。

– D.Kovács
19年11月13日在12:36

#9 楼

正如其他人已经指出的那样,出现8个字符或更少字符的主要原因是处理不支持此功能的旧系统。合理的上限。可以说是500个字符。认为提供密码超过500个字符的任何人都不是很好,这不是没有道理的。 Bcrypt已被广泛使用,并且据我所知,通常认为它是哈希密码的好/强选项,它只能处理前72个字符。超过72个字符的所有字符都将被丢弃。如果我的密码长度为100个字符,而您的密码为150个字符,则如果它们以相同的72个字符开头,则bcrypt会认为它们是相同的。强制执行72个字符的限制,以确保身份验证系统将所有唯一密码实际上视为唯一。

评论


以确保您的身份验证系统实际上将所有唯一密码视为唯一。对不起,但是你不能。这就是为什么我们使用加密强度高的哈希值。

–ch3ka
2014年11月4日,1:11

我认为没有任何理由执行一个规则,即每个用户都应该具有唯一的密码。两个不同的用户可以很好地拥有相同的密码。 bcrypt丢弃所有超出前72个字符的唯一缺点是,任何试图破解密码的人都只能尝试最大长度为72的字符串,即,即使我将密码设置为100个字符长,额外的28个字符也不会给出我还有其他安全措施。

–欢乐巴蒂亚(Ajoy Bhatia)
17年11月28日在0:19

扔掉字符的问题在于,有十二个用户可以使用相同的80个字符,然后使用更多特定于该用户的字符-因此每个人都有相同的密码,而且他们可能彼此认识。

– gnasher729
16小时前

#10 楼

许多网站都认为不需要长密码,因为它具有蛮力保护(例如限制每个IP的登录尝试次数),长密码和短密码的区别不大,在两种情况下,都需要数年的时间才能尝试所有可能的组合。

一种重新建议是使用一个带AZ AZ 0-9的长随机字符(!@#$%^&* -_ = + / \'“)。 />

评论


根据RDBMS的不同,其中一些其他字符可用于SQL注入,并希望最终在清除输入参数时将其省略,因此我在不提及允许的字符可能有所不同的情况下,不建议使用它们,而应与警告。

– TildalWave
13年4月2日在19:34

#11 楼

Jet的另一个原因是UI设计和整体用户体验:当每个输入都显示为星号或大点时,达到输入字段的可见长度时,对于许多用户而言,发生的情况并不明显。这可能会使用户感到困惑并引起负面情绪(不太可能买东西,回来或将其推荐给朋友)。技术解决方案是可行的,但限制长度例如,例如最多20个字符,以便光标永远不会到达输入字段的末尾。

#12 楼

我说这有三个主要原因:


旧式系统不支持特殊字符
希望通过保持用户的使用来减少支持开销并提高系统利用率密码实际上很容易记住。换句话说,如果您让用户制作和使用他们不记得的密码,他们将因此而烦恼您,或者由于麻烦而停止使用该网站。
开发人员不想不得不担心会从不受信任的用户那里解析特殊字符,这可能很危险

过去,最主要的原因可能是缺乏支持密码的能力(#1),而今天可能是缺乏支持他们的愿望-主要来自#2,但部分来自#3。

#13 楼

由于存在其他限制(通常仅接受数字),因此它也可能受以下事实的激励:它允许(或可能允许,如果有一天需要的话)通过容量有限的某些界面输入密码...

这就是为什么许多银行都对Web访问密码设置了此类限制,以允许通过仅具有数字小键盘(ATM,电话等)的旧系统进行访问的原因。

#14 楼

我所知道的所有银行站点都有一个类似pin的系统,它会在3次密码尝试失败后锁定您的帐户。这意味着长密码会适得其反,因为它们更容易被键入或忘记,特别是因为您看不到它们(如果可以看到它们,安全性甚至会更差)。

例如。一个用于智能手机的密码系统,您在其中输入4个数字,在3次尝试中猜中的几率是0.03%。如果使用8位数字,则正确猜中密码的可能性(如果序列是随机生成的而不是愚蠢选择的)变得很小,以至于如果您尝试猜测70亿个人密码,则平均只能猜对209个人密码。如果允许使用字符和/或特殊字符,则猜测的机会会更小,分别乘以1 ^ -4或1 ^ -6的倍数。

即使允许用户选择密码和会以半预测的方式选择它们,在3次尝试中就不可能破解任何特定帐户,即使您拥有很多数据(例如家庭中的所有生日和名字),您的平均值也不会提高太多。家庭中的每个人和这个人的每个朋友。而且您也不大可能拥有针对大量人口的可靠而全面的此类清单。