我应该在密码上加上最大长度吗？
nic*_*ckf 153 security encryption passwords
我可以理解,对密码施加最小长度非常有意义(为了节省用户),但我的银行要求密码长度在6到8个字符之间,我开始想知道......
- 难道这不会让蛮力攻击更容易吗？(坏)
- 这是否意味着我的密码未加密存储？(坏)
如果某人(希望)有一些优秀的IT安全专业人员为他们工作,那么我是否应该考虑做类似的事情？这有什么优点/缺点？
epo*_*olf 186
密码被散列为32,40,128,无论长度如何.最小长度的唯一原因是为了防止容易猜到密码.没有最大长度的目的.
强制性的XKCD解释了如果你施加最大长度,你为什么要对你的用户造成伤害:
- 可悲的是,假设密码始终是哈希值.密码的最大长度是以明文形式存储的密码的症状. (37认同)
- 叹息,即使在PayPal,"正确的马电池主食"是超过*<审查>*最大长度的8个字符...*headdesk* (14认同)
- 至少在ATM上,如果你尝试暴力攻击,它会吃你的卡.我所指的是仅在线登录的密码. (11认同)
- 也许银行可能会选择限制密码,因为在ATM上输入的内容不能超过8个字符. (6认同)
- @kleinfreund因为如果它被散列,密码长度对它们无关紧要(散列函数将_any_长度的字符串转换为固定长度). (3认同)
- 密码和PIN是两回事.好点,尼克. (2认同)
tar*_*ate 74
在密码字段中指定的最大长度应该被视为安全警告:任何明智的,注重安全的用户必须承担最坏的情况,并期望该网站按字面意思存储您的密码(即没有哈希,如epochwolf所述).
在这种情况下:(a)尽可能避免像瘟疫一样使用这个网站[他们显然知道关于安全的问题](b)如果你必须使用网站,请确保你的密码是唯一的 - 不像你在别处使用的任何密码.
如果您正在开发一个接受密码的网站,请不要设置愚蠢的密码限制,除非您想要使用相同的刷子涂焦油.
[在内部,当然,您的代码可能只将第一个256/1028/2k/4k(无论如何)字节视为"重要",以避免对猛犸密码进行处理.
- 我也发出这样的网站标准的电子邮件,提的是,他们强迫我使用较短的,不太安全的密码,我也正好重用每个网站强加这种无聊的限制上.这让他们知道,这是个问题,也可能给乔编码器的一些杠杆展现给上级领导:证据表明,用户实际认为不好的网站,作为这样的结果. (14认同)
- @benc肯定,这是可能的,但重点是作为用户,你无法知道这是否是他们正在做的事情.最大长度(特别是短的长度)是一个警告标志,我认为最好假设最坏的(或与提供商联系以让他们确认). (5认同)
- 我不确定你应该假设密码最大值意味着他们存储纯文本密码.有时,它们会截断输入,只是将第一个x字符传递给散列().(检查方法是将密码设置为超出限制,然后尝试使用超出最大长度的密码字符的变体进行登录). (3认同)
- 请详细说明。这个答案只是一个陈述。 (2认同)
- 最大密码并不一定意味着它以纯文本形式存储；这可能是出于技术原因，例如 bcrypt 只允许最多 72 个字符的密码。 (2认同)
Jas*_*git 54
如果您接受来自不受信任来源的密码,则允许完全无限制的密码长度有一个主要缺点.
发件人可能会尝试给您这么长的密码,导致其他人拒绝服务.例如,如果密码是1GB的数据,那么您将花费所有时间接受它,直到内存不足为止.现在假设此人向您发送此密码的次数是您愿意接受的次数.如果您对所涉及的其他参数不小心,则可能导致DoS攻击.
按照今天的标准,将上限设置为256个字符似乎过于慷慨.
- 您仍然可以发送最大限制的1GB数据.执行限制的软件几乎总是在Web服务器之后. (34认同)
- 在执行计算密集型操作之前,您仍然可以删除除前256个之外的所有内容.在1gb数据上运行sha哈希比在256个字符上使用相同的哈希要多*多*. (6认同)
- @Piskvor:但无论如何都无法阻止1 GB的字符串.用户始终可以请求http://www.example.com/?password=abcabcabcabc ...并根据需要提出他的请求.标准的DoS. (4认同)
- @Piskvor和Eyal,幸运的是,Apache和IIS(以及可能是其他成熟的服务器)限制了通过URL传递的字段长度:http://www.boutell.com/newfaq/misc/urllength.html (4认同)
- @Eyal:在Web应用程序的客户端发生的任何事情本质上都是不可信的; 因此,哈希变成了密码等价物,这使得这是一种无用的练习.(Web浏览器可能不接受1 GB文本输入,自定义客户端可能会在"thisisthehashedpassword"表单字段中发送1 GB字符串) (2认同)
kra*_*etz 13
OWASP身份验证备忘单现在不鼓励最大密码长度限制
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
引用整段:
较长的密码提供了更多的字符组合,从而使攻击者更难以猜测.
密码的最小长度应由应用程序强制执行.短于10个字符的密码被认为是弱的([1]).虽然最小长度执行可能会导致在某些用户之间记忆密码出现问题,但应用程序应鼓励他们设置密码(句子或单词组合),这些密码可能比典型密码长得多,但更容易记住.
最大密码长度不应设置得太低,因为它会阻止用户创建密码短语.典型的最大长度为128个字符.短语短于20个字符的短语通常被认为是弱的,如果它们只包含小写拉丁字符.每个角色都算!!
确保用户输入的每个字符实际包含在密码中.我们已经看到系统以比用户提供的更短的长度截断密码(例如,当他们输入20时截断为15个字符).这通常通过将所有密码输入字段的长度设置为与最大长度密码完全相同的长度来处理.如果您的最大密码长度很短,如20-30个字符,这一点尤为重要.
- 此源不会阻止最大密码长度限制,它不鼓励**低**(小于128个字符)最大密码长度限制. (10认同)
我可以想象实施最大密码长度的一个原因是前端必须与许多遗留系统后端接口,其中一个后端本身强制执行最大密码长度.
另一个思考过程可能是,如果用户被迫使用短密码,他们更容易发明随机乱码而不是容易猜到(通过他们的朋友/家人)的短语或昵称.这种方法当然只有在前端强制执行混合数字/字母并拒绝具有任何字典单词的密码(包括用l33t-speak编写的单词)时才有效.
强加一些最大密码长度的一个潜在有效原因是散列它的过程（由于使用了慢散列函数，例如 bcrypt）占用了太多时间；可能会被滥用以对服务器执行 DOS 攻击。
再说一次，服务器应该配置为自动删除花费太长时间的请求处理程序。所以我怀疑这会是一个很大的问题。
| 归档时间： |
|
| 查看次数： |
68155 次 |
| 最近记录： |