我注意到密码有一个奇怪的地方(嗯,据我所知)。例如,如果我在登录时输入了错误的密码,系统会延迟几秒钟才告诉我。当我尝试sudo
使用错误的密码时,我还必须等待 shell 说“抱歉,请重试”。
我想知道为什么“识别”不正确的密码需要这么长时间?这已经在我使用的几个发行版(甚至 OSX)上看到了,所以我认为这不是特定于发行版的事情。
答案1
这是一个安全问题,实际上不需要很长时间就能意识到这一点。这解决了 2 个漏洞:
这会限制登录尝试,意味着某人无法以最快的速度攻击系统以尝试破解它(每秒 100 万次尝试?我不知道)。
如果它在验证您的凭据不正确后立即执行此操作,您可以使用它使您的凭据无效所需的时间来帮助猜测您的部分凭据是否正确,从而大大减少猜测时间。
为了防止这两件事系统只需要一定的时间来完成,我认为你可以使用 PAM 配置等待时间(看看迈克尔的回答)。
安全工程(第三版,亚马逊|第二版,免费)对这些问题给出了更好的解释。看第 2 章 (PDF)— 特别是第 2.4 条和第 2.5.3.3 条。
答案2
这是有意为之,试图限制暴力破解。您通常可以通过查找FAIL_DELAY
配置条目/etc/login.defs
并更改其值(3
默认情况下是秒)来修改它,尽管该文件中的注释听起来 PAM2
无论如何都会强制执行至少一秒的延迟
答案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。