| ▲ | onraglanroad 2 days ago | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
| ▲ | timhh 2 days ago | parent [-] | ||||||||||||||||||||||||||||||||||
> 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. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||