The code you linked to isn't the code for a wrong password. It's a check to make sure you're using a TTY. That code isn't to prevent brute force. The delay there is 10 seconds.
It's really really not. By default PAM has a difficult-to-disable 2ish second minimum delay for all authentication methods. However this is completely pointless for local password authentication because PAM checks password using unix_chkpwd, which has no delay. The comment I linked to is explaining that unix_chkpwd has a silly security theatre delay if you try to run it in a tty, but that's trivial to avoid.
If you want to brute force local password authentication you can just run unix_chkpwd as fast as you like. You don't need to involve PAM at all, so its 2 seconds delay achieves nothing.
It maybe does more for remote connections but I'm not sure about that either - if you want to check 10k ssh passwords per second what stops you making 10k separate connections every second? I don't think the 2 second delay helps there at all.
> Change both the config files and you can remove the delay if you want.
This is extremely complicated. See the comments in the issue for details.
Not for local password authentication.
https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...
Yes, for local password authentication.
The code you linked to isn't the code for a wrong password. It's a check to make sure you're using a TTY. That code isn't to prevent brute force. The delay there is 10 seconds.
The 2 second delay is in support.c at https://github.com/pibara/pam_unix/blob/5727103caa9404f03ef0...
It only runs if "nodelay" is not set. But you might have another pam module setting its own delay. I have pam_faildelay.so set in /etc/pam.d/login
Change both the config files and you can remove the delay if you want.
> Yes, for local password authentication.
It's really really not. By default PAM has a difficult-to-disable 2ish second minimum delay for all authentication methods. However this is completely pointless for local password authentication because PAM checks password using unix_chkpwd, which has no delay. The comment I linked to is explaining that unix_chkpwd has a silly security theatre delay if you try to run it in a tty, but that's trivial to avoid.
If you want to brute force local password authentication you can just run unix_chkpwd as fast as you like. You don't need to involve PAM at all, so its 2 seconds delay achieves nothing.
It maybe does more for remote connections but I'm not sure about that either - if you want to check 10k ssh passwords per second what stops you making 10k separate connections every second? I don't think the 2 second delay helps there at all.
> Change both the config files and you can remove the delay if you want.
This is extremely complicated. See the comments in the issue for details.
4 replies →