为什么输入错误密码后延迟大？

Question

我注意到关于密码的一个奇怪的（好吧，据我所知）事情。例如，如果我在登录时输入了错误的密码，系统会延迟几秒钟才告诉我。当我尝试sudo使用错误的密码时，我还必须等待 shell 说“对不起，再试一次”。

我想知道为什么“识别”不正确的密码需要这么长时间？这已经在我使用的几个发行版（甚至 OSX）上看到了，所以我认为这不是发行版特定的东西。

Answer 1

这是一个安全问题，它实际上并不需要很长时间来实现。这解决了2个漏洞：

1. 这会限制登录尝试，这意味着有人无法以尝试破解它的速度冲击系统（每秒尝试 100 万次？我不知道）。

2. 如果它在验证您的凭据不正确后立即执行此操作，您可以使用它使您的凭据无效所花费的时间来帮助猜测您的部分凭据是否正确，从而大大减少了猜测时间。

为了防止这 2 件事，系统只需要花费一定的时间来完成，我认为您可以使用 PAM 配置等待时间（请参阅 Michael 的回答）。

Security Engineering（第 3 版，亚马逊|第 2 版，免费）对这些问题给出了更好的解释。请参阅第 2 章 (PDF) — 特别是 §2.4 和 §2.5.3.3。

Answer 2

这是故意的，试图限制蛮力。您通常可以通过在其中查找FAIL_DELAY配置条目/etc/login.defs并更改其值来修改它（3默认情况下我的是秒），尽管该文件中的注释使它听起来像 PAM2无论如何都会强制执行至少第二次延迟

Answer 3

在现代 linux 系统上，原因是 pam_unix.so 强加了这样的延迟。据此前报道，这可以通过改变配置上下两秒钟FAIL_DELAY在/etc/login.defs。如果您想进一步减少延迟，您必须为 pam_unix.so 提供“nodelay”选项。例如，在我的系统上，如果您跟踪从 开始的包含/etc/pam.d/sudo，您会发现您必须编辑以下行/etc/pam.d/system-auth：

auth      required  pam_unix.so     try_first_pass nullok

并将其更改为：

auth      required  pam_unix.so     try_first_pass nullok nodelay

不幸的是，我的 linux 发行版 (arch) 配置事物的方式，完全相同的system-auth文件被包含system-remote-login在 sshd 中。

虽然消除 sudo 的延迟是安全的，因为它会被记录下来，只能由本地用户使用，并且无论如何都可以被本地攻击者绕过，但您可能不想消除远程登录的这种延迟。您当然可以通过编写不只包含共享系统身份验证文件的自定义 sudo 来修复它。

就个人而言，我认为 sudo 的延迟（并忽略 SIGINT）是一个大错误。这意味着知道自己输入错误密码的用户无法终止进程并感到沮丧。当然，您仍然可以使用 Ctrl-Z 停止 sudo，因为 sudo 不会捕获 SIGTSTP，并且在停止之后您可以使用 kill -9 (SIGKILL) 将其杀死。做起来很烦人。所以这意味着自动攻击可以以超高的速度在伪终端上发射 sudo。但是这种延迟让合法用户感到沮丧，并鼓励他们挂起他们的 root shell 而不是退出它们以避免再次 sudo。