首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >检查注册时提供的密码是否被泄露到任何列表上是个好主意吗?然后,阻止用户使用它?

检查注册时提供的密码是否被泄露到任何列表上是个好主意吗?然后,阻止用户使用它?
EN

Security用户
提问于 2022-01-07 22:57:10
回答 2查看 209关注 0票数 1

不久前,有人告诉我,检查注册时提供的密码是否包含在泄露的密码列表中是个好主意。我不是在信息安全领域,但我真的很喜欢认真对待这样的方面,我总是考虑密码的问题。网站受累提供了一个API来完成这样的任务,这是非常好的。

我不确定这是否会对我的申请产生积极的影响,我想它会的。不过,我想听听你们中那些从事入侵测试的人的意见。

你可能会问自己:如果他的想法是在注册时防止某些事情发生,他为什么要谈论入侵测试?这个想法是,如果用户不能使用已经泄露的密码,那么攻击者猜密码攻击的机会就会更小,例如在字典攻击中。当然,要对付这样的攻击,仅仅实现问题中提到的这个机制是不够的,我知道这是不够的,但是它将是使应用程序更加可靠的又一个机制。

在执行了搜索之后,我从Okta开发人员网站找到了一个有趣的资源。

不久前,美国国家标准与技术研究所(NIST)正式建议检查用户提供的密码,以防止现有的数据泄露。新的NIST建议意味着,每次用户提供密码时,您作为开发人员都有责任根据已被破坏的密码列表检查他们的密码,并防止用户使用先前被破坏的密码。例如,假设你的密码“fdsah35245!!3”在2014年的索尼数据泄露中被破解。一旦这些密码被泄露,攻击者就会下载已泄露的密码,并使用它们登录其他用户的帐户。

因此,正如引用中提到的,这个想法似乎是好的和有效的,然而,也许这会产生可用性问题,会不会发生用户对这种机制感到不舒服的情况?无论如何,这似乎是一个好主意,实现这个机制可以使应用程序更安全,但也许我错了?

让我知道你是怎么想的,我的目标是成为一个更好的开发人员,我不喜欢创建易受攻击的应用程序的想法。

EN

回答 2

Security用户

发布于 2022-01-09 06:53:55

正如您已经注意到的,当前的建议是这样做,并且同时存在列表和API(例如,来自haveibeenpwdeda.k.a)。HIBP( HIBP)支持这一点。它提供了比简单的“复杂性”规则更强的保护(这常常导致错误的安全性,甚至使用比其他规则更弱的密码,因为满足这些要求的额外更改对一个人来说很难记住)。

至于让人感到不舒服的问题,如果你告诉某人他们的候选密码在已知的密码清单上,你就是在帮他们的忙。很明显,你应该用一种清晰的方式来表达错误,而不是显得不尊重。“该密码已知已在另一个站点上使用,并已被泄露。请选择一个新的、唯一的密码。”,可能与HIBP的Pwned密码页或类似的链接有关。

您可以通过下载被破坏的密码列表并在本地进行检查,从而避免实际发送密码,甚至它的散列,不过,当添加新的漏洞时,您会希望更新本地列表(HIBP支持此操作,或者有其他密码列表)。请注意,HIBP API的工作方式实际上对不泄露密码是非常好的(它接受候选密码,在客户端散列它,并且只向HIBP的服务器发送一个严重截断的哈希版本,HIBP的服务器用一个已知密码列表进行回复,其中包含一个哈希片段,用于客户端与用户提交的密码进行比较)。尽管如此,有些人还是希望他们的密码不会以任何形式离开你的系统。

请注意,如果您使用被破坏的密码列表和复杂性要求,您将浪费您自己和您的用户的时间。只要有一个长度要求(8个字符是安全的实际最低要求,但更长更好),没有字符要求或限制,只检查密码没有出现在任何入侵列表上,并且在其他方面是不可预测的(例如,不包含站点名称、用户名等)。

以下是相关指南(取自NIST的SP-800-63B第5.1.1节,最后一次更新于2020年):

在处理建立和更改记忆秘密的请求时,验证者应将潜在的秘密与包含已知常用、预期或泄露的值的列表进行比较。例如,清单可能包括但不限于:

  • 从先前的入侵身体中获得的密码。
  • 字典词。
  • 重复或顺序字符(例如‘aaaaaa’,‘1234 e.g.’)。
  • 特定于上下文的单词,例如服务的名称、用户名及其派生词。

如果在列表中发现了所选的秘密,CSP或验证者应通知订阅者他们需要选择不同的秘密,应提供拒绝的理由,并要求订阅者选择不同的值。..。验证者不应强加其他组合规则(例如,要求不同字符类型的混合或禁止连续重复的字符)来记忆秘密。验证者不应要求任意更改记忆的秘密(例如,定期更改)。但有证据证明鉴定人妥协的,核查员应当强制变更。验证者应允许索赔人在输入已记忆的秘密时使用“粘贴”功能。这为密码管理器的使用提供了便利,密码管理器被广泛使用,并且在许多情况下增加了用户选择更强记忆秘密的可能性。

票数 2
EN

Security用户

发布于 2022-01-07 23:14:57

嗯……这不是一个愚蠢的想法:我们已经习惯了限制最小密码长度或最小数量的字符类。拥有已知的密码黑名单在密码破解者使用的列表中,不应该让太多的用户感到不安。

国际水文学组织,真正的问题是,这些名单可能变化很快。如果密码模式上设置的约束越多,则允许用户保留密码模式的时间越长。

出于这个原因,我会提出一个想法,通过众所周知的密码破解(约翰,开膛手,等等)。在用户数据库中,及时使用自动邮件警告用户,他们的密码已经被自动猜出,他们应该修改密码。无论是强制还是咨询,都可能取决于数据的敏感性和您想提供的用户体验。

票数 1
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/258601

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档