尽管为每种目的选择唯一的密码是一个好主意,但实际上很少发生这种情况。因此,许多人从容易记住的个人密码池中选择密码。在不经常使用的系统中进行身份验证时,很有可能会依次尝试使用该池中的许多密码。另外,如果输入错误,失败的密码与实际密码非常接近。

由于几乎没有人描述有效的密码策略,包括如何处理被拒绝的密码,因此应该假设接收到的密码开始收集在出售给最高出价者的数据库中?

是否有实施指南?候选密码被拒绝时通常会发生什么?他们是被记录,立即丢弃还是闲逛直到垃圾被收集?失败的密码处理过程是否属于任何经过审核的控件的一部分?关于如何处理有效密码,似乎有很多实施要求和建议,但对于拒绝的密码值却含糊不清。

编辑

我将尝试在此处列出记录失败的登录安全性凭证的各种实现,以了解该过程的广泛程度:

内容管理系统:


通过登录失败的日志插件进行Joomla


此小插件收集有关每次尝试登录失败的日志您的Joomla网站的管理员,并通过用户名,密码,IP地址和错误向该网站的超级管理员发送有关每个电子邮件的电子邮件。


KPlaylist v1.3和v1.4 -一个免费的PHP系统,可通过Internet提供您的音乐收藏。


在apache错误日志中记录了失败的登录尝试的用户名和密码。


Drupal 5.x低于版本5.19和Drupal 6。 x在6.13版之前。


当匿名用户由于输入错误的用户名或密码而导致登录失败,并且他所在的页面包含可排序的表时,该表的链接中将包含(错误的)用户名和密码。如果用户访问这些链接,则密码可能会通过HTTP引荐来源网址泄露给外部站点。

独立软件

Symantec Client Security 3.1随附的Reporting Server和SAV CE 10.1


登录尝试失败后,可能会泄露Symantec Reporting Server的管理员密码。


Linux:

通过修改后的auth-passwd.c进行OpenSSH;通过重载pam_sm_authenticate函数使用PAM

EDIT#2

似乎已经达成共识,并且记录失败的密码或PINS被视为严重/主要的安全隐患,但是,据我所知,以下标准未提供专门解决此风险的指南,经过审计的程序或控制措施:


PCI-DSS:8.4中涉及的密码程序。和8.5。 (失败的密码仅在传输期间受到保护;验证后不视为密码,因此不需要保护)
FIPS140-2:认证在4.3中解决(失败的认证数据的生命周期仅得到部分解决)


评论

相关(关于一个特定情况,这个问题更笼统):是否应在错误消息中显示密码?

用户应该被延迟和登录,但不能使用纯文本密码。您需要让用户使用单独的线程或上下文才能执行此操作,否则在某些情况下可能会冻结其他用户。

相关:security.stackexchange.com/questions/8323/…

@AndrewSmith“您需要让用户使用单独的线程或上下文才能执行此操作”能否解释“上下文”的含义吗?

@curiousguy的含义是,由于经常在多个服务器上使用相同的密码(虽然不明智,但仍然很常见),如果sshd收集了这些密码,它们对于传播攻击很有用。使用ssh键可以最大程度地减少曝光。出于相同的原因,服务器上的ssh客户端被木马攻击,这就是为什么从可疑服务器(或任何可以避免的服务器)中使用SSH是不明智的。可以通过使用关键试剂来进一步限制暴露,但是它本身具有暴露量,因此...

#1 楼

记录密码尝试失败的值(明文或其他形式)似乎是一种安全反模式。我从未见过执行此操作的Web应用程序,而且我不知道有任何默认系统服务(例如SSH)可以执行此操作。如下面的@tylerl所指出的,大多数系统仅记录有关访问尝试的元信息(例如,用户名,时间,也许是IP地址等)。

为什么这应该是安全的反模式

另一方面,我可以想到以下三个原因来记录失败的密码尝试的值是一个坏主意:

1。用户Typos

人们误输入一个或两个字符的密码非常普遍。检查失败尝试的日志文件将使许多这样的问题容易找出,尤其是如果您可以将失败尝试的序列与成功的身份验证进行对比。猜猜并检查

许多人都有两到三个密码,可以循环使用所有密码。因此,当他们忘记在给定站点上使用的密码时,他们会循环浏览所有密码,直到找到匹配的内容。这将使在其他站点上入侵其帐户变得微不足道。

3。 Log Bloat

存储失败的密码对于当今生产中的绝大多数身份验证服务没有任何用处。尽管可能存在一些极端情况,但对于大多数人而言,存储此数据只是在浪费磁盘空间。

有关立法/标准

我不知道专门解决存储失败登录尝试过程的任何标准(PCI,HIPAA等),但我认为鉴于以上事实,可以提出一个很好的法律论据,说明为什么通常适用于存储密码的相同标准也应适用于密码输入失败的尝试。换句话说,您可以提出一个法律论据,认为失败的密码仍然绝对是密码,因此,它必须遵循相同的标准。

虽然我当然不是律师,但我不想让法官决定我是否疏忽大意或违反行业标准,因为失败的密码以明文形式存储,而消费者则遭受了后果。我认为这不会以有利的决定而告终。

我同意OP的观点,即对于各个标准机构专门解决此问题(如果他们确实尚未解决)可能会有所帮助。为此,我的建议是创建一个完全不存储密码尝试失败值的合规性标准。

评论


在HIPAA下,我认为您需要生成一个失败的登录尝试审核记录(没有密码信息),但是他们对日志记录没有任何评论。如果不在HIPAA中,则像IHE这样的实现框架都需要它。

–奥莱西
2012年7月5日在3:34



@Oleksi好点。我已经更新了答案,以指定我的意思是存储访问尝试的值。医疗保健行业中的任何软件都应维护成功和失败访问尝试的日志,作为HIPAA /有意义使用审核控制的一部分。当然,该日志不应包含密码值。

–马克
2012年7月5日在3:41



@DrewLex-Facebook是关于安全性和隐私性的最佳范例。

–猎犬
2012年7月5日在11:48

@Drew Lex-尽管facebook仍然经常出现安全漏洞/隐私漏洞,但我怀疑它们再也记录了错误的密码尝试(并且businessinsider从匿名“朋友”那里指控Z吹嘘这并不能证明这实际上是在做的-人们在撒谎) 。相对于一个拥有真正专业人员的十亿美元的跨国公司,他们担心自己做的事情可能只会对做违法的事情。

– jimbob博士
2012年7月6日15:16



我的老板最初希望我将失败密码的SHA256锁定在表中,然后我设法说服了他。但是我认为存储最后一个失败密码的bcrypt hash + salt并使用它来确定是否重试了相同的错误密码可能是有用的(我们有一个IoT用例,设备可能会不断尝试自动登录。密码错误)

–安迪
19年4月11日在0:51

#2 楼

为任何应用程序记录纯文本密码没有合法目的;特别是对于不正确的登录。可能是偶然记录的-我已经随便查看了auth.log的其他用途,看到用户不小心在登录字段中输入了密码(并且我确实记录了登录字段,以查看尝试登录的帐户) -但是,我通知了用户,他们更改了密码。
另一方面,作为用户,保守的假设是,您使用的每个随机应用程序都会记录错误尝试的每个密码。这就是为什么要循环使用少量(三个)随机密码,而不是在加密的密码列表中(可能使用keepass之类的工具)管理的每个站点使用唯一密码的原因,这是个坏主意。
请注意,businessinsider.com指控Mark Zuckerberg(facebook创始人)使用来自thefacebook.com(facebook的早期版本)的登录名/密码组合日志(甚至来自不正确的条目)来入侵哈佛深红记者的电子邮件帐户。调查他。从每日邮寄::

然而,在进一步提出索赔要求之后,扎克伯格显然担心报纸最终将在他身上留下一个故事。
《商业内幕》声称他随后告诉朋友他如何曾入侵深红员工的帐户。
据称他告诉朋友,他使用TheFacebook.com搜索说自己是深红员工的成员。
然后,据称他检查了登录失败的报告。看看是否有任何Crimson成员曾经在TheFacebook.com中输入错误的密码。

还有些相关的xkcd(想象一下,邪恶帐户也记录了尝试输入的密码以提高其成功率)。 >

评论


+1提及XKCD就足以说明一切

–woliveirajr
2012年7月10日在20:04

@dr jimbob-关于“没有合法目的记录任何应用程序的明文密码”-如何确定用户帐户是否受到暴力攻击?

–德鲁·莱克斯(Drew Lex)
2012年7月14日在1:29

@Drew Lex-您可以(并且应该)记录某人在某个时间从IP地址向某个用户的帐户输入了错误的密码,并可能启用了额外的安全性(要求验证码,重试之间的延迟,阻止IP地址,锁定帐户等),如果失败的登录次数太频繁(例如,从大约5次连续尝试开始)。但是没有合法的理由来记录他们实际输入的密码。

– jimbob博士
2012年7月16日在20:07

XKCD +1,其中包含所有必需的信息;)

–拉杜·马里斯(Radu Maris)
13年6月6日在15:31

@drjimbob,我有一个想法,我问过一个问题,这是否代表您的观点?谢谢security.stackexchange.com/questions/66484/…

–dav
15年3月11日在12:24

#3 楼

记录身份验证尝试已失败以及针对该用户的事实并不罕见。事实证明,这在法医故障排除中非常有用。从安全的角度来看,记录被拒绝的密码是非常罕见且不负责任的。此信息无济于事,可以对您不利。

EDIT
您应该希望能够有信誉良好且组织良好的公司不会出售您的密码信息,因为如果发现的话,对他们真的很不利。但是为了您自己的安全,您应该始终准备好将自己提供给您的信息用于对自己的使用,因为这总是有可能的。对于无法可靠建立声誉的任何组织来说,这都是两倍。

评论


+1我调整了答案以明确说明我的意思是记录密码尝试的明文值。我还引用了您的回复,其中提到了哪些元信息对于审核/日志记录很有价值。

–马克
2012年7月5日,下午3:34

#4 楼

上面有一些很棒的答案,因此,这只是美国政府警察对处理机密信息的计算机系统进行管理的一种快速简化的观点。

(1)整个计算机系统必须受到保护该计算机上任何数据所需的最高标准。这包括存储在机器上或机器外的日志。例如,如果您有意或无意将“秘密”数据放在计算机上,则该计算机的每个部分现在都必须作为“秘密”信息加以保护。即使您有一台未分类的计算机(例如在家里)收到了包含分类信息的电子邮件,情况也是如此。整个计算机及其上的所有内容现在都归为“秘密”。

(2)对该计算机的密码也归为该计算机上任何数据所需的最高保护级别。 />
,例如,如果该计算机上有任何“秘密”数据,则无论密码存储在哪里,它也需要相同级别的保护。在您所应用的标准(例如PCI-DSS,NISPOM等)中,如果要求对密码进行保护(例如散列和加盐),则不能在日志中使用明文形式的密码。

因此,总而言之,如果对您的计算机系统应用了任何法规方案,并且该法规规定您不能使用明文密码,那么您的日志中就不能使用明文密码。

评论


我同意应该将通过密码字段输入的任何字符串视为“用户数据”或“密码数据”,无论结果是否有效。不幸的是,“密码”被定义为可验证的字符串,这意味着不满足此条件的值将不被视为密码。没有标准定义“密码”的更广泛定义。 SP800-53对失败的密码值保持沉默。

–德鲁·莱克斯(Drew Lex)
2012年7月14日的1:39

用户断言为安全令牌的任何信息(即使拼写错误)也将被任何主管监管机构视为密码。一个安全管理器使用一个论点,即认为用户断言的密码无法对用户进行身份验证不需要系统级别的保护,因此应以渎职为由将其从自己的位置上删除。在大多数受监管的环境中,我还希望它们在受监管的安全程序中被禁止从事未来的工作。更重要的是,这会使他们看起来异常业余。

–在架子上
2012年7月19日在23:12

#5 楼

否。通常,用户拥有一组密码,然后遍历他们试图找出给定站点使用的是密码。记录只是意味着当您受到攻击时,他们的后备选项就会添加到任何打您的人的破解池中。