Microsoft表示它正在动态禁止Microsoft帐户和Azure AD系统中的通用密码。 […] Microsoft每天看到超过1000万个帐户受到攻击，并且该数据用于动态更新禁止的密码列表。
这是基于用于
是否可以构建一个安全的系统来检查密码更新是否与其他人的密码相对应，并在密码太常见的情况下将其拒绝？
#1 楼
在Microsoft，我们禁止攻击和附近变种中最常用的密码。我们并不是基于我们的用户群，因为攻击的发生，他们（由于系统）不会共享这些密码。攻击列表通常来自研究漏洞。攻击者足够聪明，可以查看列表以找出高概率的密码，然后对这些高频率单词进行蛮力攻击等。我们将查看相同的列表以及攻击方式，以确定我们的禁止列表。
希望这会有所帮助。
评论
我们是谁”？
– techraf
16年5月27日在5:14
MSFT。 Azure AD身份保护团队的小组项目经理Alex Weinert来源
– TJ-
16年5月27日在5:21
我不确定我了解“动态”部分：（来自OP源）（...），并防止用户使用在攻击列表（...）上找到的密码。这意味着将检查错误的新密码还是现有的错误密码将触发某些操作（例如帐户锁定）？
– WoJ
16年5月27日在14:19
@ TJ- Aaaaand更改了我的LinkedIn密码。
–很少需要“莫妮卡在哪里”
16年5月27日在23:26
该答案目前尚不明确，我建议重新措词以使其更清楚。 “ [用户]不共享这些密码”是什么意思（我可以猜测，只有80％的人确定我是对的）？如果密码在禁止清单上，实际后果是什么？为什么会有多个列表？
–彼得
16年5月28日在9:42
#2 楼
实际上，在决定将新用户的密码阻止为“太常见”之前检查现有帐户密码的系统将是自欺欺人的。您不仅要让用户或攻击者知道实际上该密码对某些帐户有效，而且对许多帐户也有效。具体地，公共阈值-它们中的1。因此，本文中描述的方法实际上是Microsoft用来禁止Microsoft帐户和Azure AD通用密码的方法。它是已知的普通和/或弱密码，暴力访问尝试中常用的密码以及确定为过于相似的那些密码的变体的组合。
评论
因此，Microsoft不会禁止在Accounts / Azure上使用太普遍的密码，但是在可以为其找到数据的所有服务上使用太普遍的密码？
–trysis
16年5月26日在22:17
@trysis是的，这是正确的。
– PwdRsch
16年5月26日在22:45
@trysis和服务，是指已经被黑客入侵的网站？基本上，该算法通过从收集到的违规数据中列出大量“已知”密码来学习其他网站的错误，对吗？我认为这样的数据库很容易卖给其他公司。
–oldmud0
16年5月26日在23:21
您在回答的第二段中所说的内容似乎与Microsoft在其博客文章中所说的一致。但是，第一段是不正确的。有一些方法可以跟踪最常见的密码并阻止它们，但这无助于闯入帐户。请参阅eecs.harvard.edu/~michaelm/postscripts/hotsec2010.pdf进行仔细分析。 （该论文的两位作者在Microsoft Research工作。）
– D.W.
16-5-26在23:30
@ oldmud0：为什么“其他公司”只要从诸如“最常用的密码列表”之类的站点下载列表，便会购买这样的密码列表； “安全毯”； “未公开：显示的一千万个密码”； “安全列表”； “今天我要释放一千万个密码”；等等。？
– David Cary
16年5月29日在17:13
#3 楼
是否可以构建一个安全的系统来检查其他人的密码是否更新密码
，如果密码太常见则拒绝该密码
吗？
有原因不这样做，但是如果我的任务是防止密码被过度使用，我会收到密码，对其进行哈希处理，然后将哈希存储在与任何用户都没有连接甚至是用于创建密码的文本的表中。哈希，或更新计数（如果已存在）。如果计数超过某个限制，建议用户选择另一个密码。一旦给出了可接受的密码，便对其进行盐腌并为用户存储盐腌的哈希值。
因此，您不必直接检查其他用户的密码，而只是检查其未加盐的哈希值。
评论
对此的精简版本可能会有所帮助（作为补充）：考虑“哈希函数”，该函数将大写字母映射为A，将小写字母映射为a，将数字映射为1，特殊字符映射为％，并立即禁止将任何哈希散列到Aaaa，Aaaa11，Aaaa1111或类似的完全过度使用的模式
–哈根·冯·埃森（Hagen von Eitzen）
16年5月29日在13:23
#4 楼
我认为最好的办法就是检查服务器端的密码弱点，这可能是一项昂贵的操作（例如，从词典中查找）。常用或检查攻击的密码也是不错的选择。MS可能首先尝试对密码进行哈希处理，然后将其与不安全的密码列表进行比较（实际上，任何实际用户都未使用过）。如果哈希失败，则在示例中它可能会尝试查找具有另一个euristic的密码强度，最后它可以拒绝或接受密码，而忘记了其非哈希版本。如果拒绝密码，则很可能会将其添加到不安全的哈希列表中。
密码弱点检查还可以考虑到常用的攻击，因此它必须是一种不断发展的算法。
具有两个优点：
您不需要存储所有不安全密码的哈希。
您可以禁止哈希中的Altogheter冲突（例如强密码）
当然，这些只是推测，我们不知道像Microsoft这样的大公司采取的密码安全措施。
作为最后的措施与真实的用户密码相比，我只对弱密码使用不同的哈希。
编辑：
为什么即使弱密码也应该被哈希？对我来说，不需要强哈希，但是哈希弱密码至少可以“保护”有价值的数据。进行一些简单的散列操作是没有代价的，但是如果有任何数据库数据泄漏，您至少知道竞争对手将无法轻易地逆转弱密码，对于未使用禁止列表或处于禁止状态的服务，这仍然可能是一个安全隐患。至少可能只会带来次要的经济利益。
因此，请回答GroundZero评论：不，对我来说，弱密码也不应该以纯文本格式存储。无论如何，简单的哈希将使公司受益。这是因为存在特定于文化的密码，要收集这些信息需要大量投资，那么为什么要以易于检索的方式存储有价值的信息？
评论
散列已知的弱密码列表并使用系统上的密码散列进行测试，这不起作用，因为您应该使用唯一的散列为每个密码加盐。这种哈希密码的方法是专门为防止彩虹表攻击而设计的。 MS应该只能在创建帐户或登录时测试您密码的弱点，因为这是您的纯文本密码暴露给他们的唯一机会。正如Alex之前提到的，MS列出了一个已知的错误密码列表（很多都是公开可用的，例如rockyou）。他们可以以此测试您的纯文本密码。
– BlueCacti
16 May 27 '11：38
@GroundZero您错过了我明确告诉不要在系统上测试哈希的方法。我的意思很简单：首先从已知的错误密码列表开始->充实该列表，只要有经验的人能够检测到新的错误密码即可（比以编程方式猜测错误的密码要容易得多）。在这个阶段，加盐是完全没有用的。您可以拥有一个云，但是如果相同的弱密码具有2 ^ 64个变体，则如果提前生成/存储XD，则无论如何它们都可以很快耗尽所有存储空间
–CoffeDeveloper
16年5月27日在12:12
评论
@NeilSmithline您可以禁止特定于您的站点的通用密码，而根本无法基于现有用户密码来执行此操作。我想这就是您的意思，但是由于区别很重要，因此我想确保清楚。也许我会在什么时候可以设置密码> 16个字符的字符。
我不知道微软的亚历克斯·韦纳特（Alex Weinert）写道：“我们每天看到超过1000万个帐户遭到攻击”的确切含义。知道什么构成对他们的帐户的攻击将非常有用。如果可以回答，请说出这个字，然后我将发布问题。
我认为OS开发人员应该聚在一起，并在OS中内置一个基于云的可互操作的密码管理器（或等效于证书/密钥）。这样，这些问题将成为过去，所有人都会赢。
@SeldomNeedy谢谢。是的，目前很难从该数据中得知。如果有人尝试使用以a开头的每个用户名登录并使用密码123456进入ZZZZZ，则可以算作数百万次“攻击”。具有讽刺意味的是，这样的攻击可能会对数千个帐户起作用。