记录被拒绝的密码是常见的做法吗?

信息安全 密码 密码管理 遵守 密码策略
2021-09-06 09:54:11

虽然为每个目的选择唯一的密码是个好主意,但实际上这种情况很少发生。因此,许多人从易于记住的个人密码池中选择密码。在对不经常使用的系统进行身份验证时,很可能会依次尝试来自此类池的多个密码。或者,如果出现拼写错误,失败的密码与实际密码非常接近。

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

有实施指南吗?当候选密码被拒绝时,通常会发生什么?他们是被记录下来,立即丢弃还是留在附近直到垃圾收集?失败的密码处理程序是否是任何审计控制的一部分?似乎有很多关于如何处理有效密码的实施要求和建议,但对于被拒绝的密码值却含糊其辞。

编辑

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

内容管理系统:

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 和 SAV CE 10.1 随附的报告服务器

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

Linux:

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

编辑#2

似乎已经达成共识,记录失败的密码或 PINS 被视为严重/重大的安全风险,但据我所知,以下标准没有提供专门解决此风险的指导、审计程序或控制:

  • PCI-DSS:8.4 中解决的密码程序。和 8.5。(失败的密码仅在传输过程中受到保护;验证后不考虑密码,因此不需要保护)

  • FIPS140-2:在 4.3 中解决的身份验证(仅部分解决了失败的身份验证数据的生命周期)

4个回答

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

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

顺便说一句,我可以想到三个原因,为什么记录失败的密码尝试的值是一个坏主意:

1. 用户输入错误

人们将密码输入错误的一两个字符是非常常见的。检查失败尝试的日志文件将使其中许多容易弄清楚,特别是如果您可以将一系列失败的尝试与成功的身份验证进行对比。

2. 猜测和检查

许多人有两三个密码,他们为所有事情循环使用。因此,他们忘记了在给定站点上使用的密码时,他们只会循环浏览所有密码,直到找到匹配项。这将使破解他们在其他网站上的帐户变得微不足道。

3. 日志膨胀

存储失败的密码对于当今生产中的绝大多数身份验证服务没有用处。虽然可能存在一些边缘情况,但对于大多数人来说,存储这些数据只是在浪费磁盘空间。

相关法例/标准

我不知道有任何标准(PCI、HIPAA 等)专门解决了存储失败登录尝试的过程,但我认为考虑到上述事实,可以提出一个很好的法律论据来解释为什么同样的标准适用于存储一般来说,密码也应该适用于密码失败的尝试。换句话说,您可以提出一个合法的论点,即失败的密码仍然是绝对的密码,因此它受制于相同的标准。

虽然我当然不是律师,但我不希望法官必须决定我是否疏忽或违反行业标准,因为失败的密码以明文形式存储,消费者承担了后果。我认为这不会以一个有利的决定而告终。

我同意 OP 的观点,即各种标准机构专门解决这个问题可能很有用(如果他们确实还没有的话)。 为此,我的建议是创建一个完全不存储失败密码尝试值的合规标准。

为任何应用程序记录明文密码没有合法目的;特别是对于不正确的登录。它可能是偶然记录的——我随便看看auth.log其他用途,看到用户不小心在登录字段中输入了他们的密码(我确实记录了登录字段以查看尝试登录的帐户)—— - 但是我通知了用户,他们更改了密码。

另一方面,作为用户,保守的假设是说您使用的每个随机应用程序都会记录错误尝试的每个密码。这就是为什么循环使用少量(三个)随机密码而不是在加密密码列表中管理的每个站点的唯一密码(可能使用诸如keepass之类的工具)是一个坏主意的原因。

在这张纸条上,马克扎克伯格(facebook 创始人)被 businessinsider.com 指控使用来自thefacebook.com(早期版本的 facebook)的登录/密码组合日志(甚至来自不正确的条目)来侵入哈佛深红记者的电子邮件帐户,正在调查他。来自每日邮报::

然而,在进一步的声明出现后,扎克伯格显然开始担心该报最终会报道他的故事。

Business Insider 声称,他随后告诉一位朋友他是如何侵入 Crimson 员工账户的。

据称,他告诉这位朋友,他使用 TheFacebook.com 搜索自称是 Crimson 员工的成员。

然后,据称他检查了一份登录失败的报告,以查看是否有任何 Crimson 成员曾在 TheFacebook.com 中输入了错误的密码。

也有点相关xkcd(想象一下,邪恶的账户也记录了尝试的密码以提高他们的成功率)。

记录身份验证尝试失败以及它是针对哪个用户的事实并不少见。这在取证故障排除中非常有用。从安全的角度来看,记录被拒绝的密码是非常罕见和不负责任的。这些信息没有任何用处,可以用来对付您。

编辑
应该希望能够期望一家信誉良好且组织良好的公司不会出售您的密码信息,因为如果被发现这对他们来说真的很糟糕。但是为了您自己的安全,您应该时刻准备好您提供的信息会被用来对付您,因为这总是有可能的。对于您无法可靠建立声誉的任何组织来说,这都是双倍的。

上面有一些很棒的答案,所以这只是美国政府关于管理处理机密信息的计算机系统的政策的一个快速和简化的观点。

(1) 必须按照该机器上的任何数据要求的最高标准保护整个计算机系统。这包括存储在机器上或机器外的日志。

例如,如果您有意或无意地将“秘密”数据放在计算机上,则该计算机的每个部分现在都必须作为“秘密”信息进行保护。即使您有一台未分类的计算机(例如在家中)收到一封包含机密信息的电子邮件,情况也是如此。整台电脑,以及上面的一切现在都被归类为“机密”。

(2) 该机器的密码也被归类为该机器上任何数据所需的最高保护级别。

例如,如果您在那台机器上有任何“秘密”数据,那么无论您在哪里存储密码,它也需要相同级别的保护。

适用于您的问题,无论您应用什么标准,例如 PCI-DSS、NISPOM 等,如果要求保护它们(例如散列和加盐),您不能在日志中使用明文密码.

所以总而言之,如果任何监管方案适用于您的计算机系统,并且该法规规定您不能有明文密码,那么您的日志中就不能有明文密码。