| ▲ | timhh 2 days ago |
| I did this! I didn't actually know that Mint had enabled this by default. That would have been a useful counterpoint to the naysayers. If you want the original behaviour you don't actually need to change the configuration - they added a patch afterwards so you can press tab and it will hide the password just for that time. > The catalyst for Ubuntu’s change is sudo-rs Actually it was me getting sufficiently pissed off at the 2 second delay for invalid passwords in sudo (actually PAM's fault). There's no reason for it (if you think there is look up unix_chkpwd). I tried to fix it but the PAM people have this strange idea that people like the delay. So I gave up on that and thought I may as well try fixing this other UX facepalm too. I doubt it would have happened with the original sudo (and they said as much) so it did require sudo-rs to exist. I think this is one of the benefits of rewriting coreutils and so on in Rust - people are way more open to fixing long-standing issues. You don't get the whole "why are you overturning 46 years of tradition??" nonsense. If anyone wants to rewrite PAM in Rust... :-D https://github.com/linux-pam/linux-pam/issues/778 |
|
| ▲ | 9dev 2 days ago | parent | next [-] |
| > If anyone wants to rewrite PAM in Rust... :-D If you do, offer support for writing modules in a scripting language like Lua or Python. PAM could make it a lot easier to just add OAuth with your company IdP, for example… |
| |
| ▲ | tetha 2 days ago | parent [-] | | Ah, but then you choose the wrong language or language runtime and distros ship old versions for 10+ years :) (compare: polkit. Both sides have their point, but I've been annoyed by this standoff a few times). |
|
|
| ▲ | 1718627440 2 days ago | parent | prev | next [-] |
| > There's no reason for it The reason is to add a delay when bruteforcing passwords. |
| |
| ▲ | hananova a day ago | parent | next [-] | | Bruteforcing is only really done with the password hashes in hand. Attacks on live systems are done with credential stuffing. | |
| ▲ | timhh a day ago | parent | prev [-] | | Definitely not for local password authentication, and I'm dubious it helps for ssh either. See my other comment. |
|
|
| ▲ | egorfine 2 days ago | parent | prev | next [-] |
| > You don't get the whole "why are you overturning 46 years of tradition??" nonsense Respectfully, we are the opposing sides of the barricades here. I was removing sudo-rs, uutils and some of the systemd-* packages from fresh Ubuntu installations until the amount of virtue signaling got really tiresome. Currently almost no Ubuntu left in my production. Hopefully Debian will not package those. PS: Rust is awesome! |
|
| ▲ | yonatan8070 2 days ago | parent | prev [-] |
| Pretty sure the 2s delay is designed to slow down brute-forcing it. |
| |
| ▲ | timhh 2 days ago | parent [-] | | Not for local password authentication. https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c... | | |
| ▲ | onraglanroad 2 days ago | parent [-] | | 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. | | |
| ▲ | onraglanroad 2 days ago | parent [-] | | 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 a day ago | parent [-] | | > 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#issuecomme... > feels like arguing with an LLM I could say the same about you, repeatedly and confidently asserting falsehoods. | | |
| ▲ | onraglanroad a day ago | parent [-] | | 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 19 hours ago | parent [-] | | 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 $?
|
|
|
|
|
|
|
|
