[timhh]

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]

> 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]

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).

[egorfine]

> 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!

[1718627440]

> There's no reason for it

The reason is to add a delay when bruteforcing passwords.

[hananova]

Bruteforcing is only really done with the password hashes in hand. Attacks on live systems are done with credential stuffing.

[timhh]

Definitely not for local password authentication, and I'm dubious it helps for ssh either. See my other comment.

[yonatan8070]

Pretty sure the 2s delay is designed to slow down brute-forcing it.

[timhh]

Not for local password authentication.

https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...

[onraglanroad]

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]

> 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]

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]

> 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.