Comment by timhh
6 months 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
> 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…
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).
> 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!
> There's no reason for it
The reason is to add a delay when bruteforcing passwords.
Bruteforcing is only really done with the password hashes in hand. Attacks on live systems are done with credential stuffing.
Definitely not for local password authentication, and I'm dubious it helps for ssh either. See my other comment.
Pretty sure the 2s delay is designed to slow down brute-forcing it.
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.
5 replies →