13 ms·

Not for local password authentication. https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c#L105-L112 https://github.com/pibara/pam_unix/blob/master/un

• onraglanroad 6mo 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/5727103caa9404f03ef04797dd581a5b7c87886b/support.c#L600 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 6mo ago
    > 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.
    • onraglanroad 6mo ago
      No, it's very simple. Do what I said in my comment. Add nodelay to the options for pam_unix.so and set pam_faildelay.so delay=0 That's it. You didn't link to any issue and the weird mistakes and justifications you're making feels like arguing with an LLM. You obviously can't run unix_chkpwd against a local account without root.
      • timhh 6mo ago
        > You obviously can't run unix_chkpwd against a local account without root. Wrong. At least check before you say something is obvious. > No, it's very simple. Even more wrong: https://github.com/linux-pam/linux-pam/issues/778#issuecomment-3233644079 https://github.com/linux-pam/linux-pam/issues/778#issuecomme... > feels like arguing with an LLM I could say the same about you, repeatedly and confidently asserting falsehoods.
        • onraglanroad 6mo ago
          No, I'm right. You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash. If you think you can, explain how. Otherwise you have to use the setuid version which won't let you run it directly. And I just removed the delay using my method. Perhaps try checking something yourself?
          • timhh 6mo ago
            I don't understand how you can be so confidently wrong about something so easily checked. :D > You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash. unix_chkpwd can access /etc/shadow because it is suid. > Otherwise you have to use the setuid version which won't let you run it directly. Haha you mean this? $ unix_chkpwd This binary is not designed for running in this way -- the system administrator has been informed Take a look at the source code I linked about 6 comments ago! > Perhaps try checking something yourself? I have. You haven't. printf 'hunter2\0' | unix_chkpwd yourusername nullok; echo $?