Posted by akersten 16 hours ago
I think it's an awful idea. Apart from making things less secure it also makes sudo's UX inconsistent with most of the other coreutils. Luckily, I don't plan on doing any more ubuntu installs.
If we know the password's length, it saves us from guessing any shorter passwords. For example, for a numeric password, knowing the length is 4 saves us from having to guess [blank], 0-9, 00-99 and 000-999. This lowers the number of possibilities from 1111 to 1000. The password has 90% of it's original strength. A [0-9a-zA-Z] password retains 98% of it's original strength
The set of all strings, of any length over A, is an infinite set, because it is the union of all sets of strings of length n for each positive integer n.
So if you don't know the length of the password, there are infinite possibilities. If you do know the length of the password, there are only finite possibilities.
Which would in turn imply that there is an infinite amount of information in knowing the length of a password - the complement of the set of n-length strings over A in the set of strings over A contains an infinite number of elements, which you can safely exclude now that you know the password is part of the finite set of n-length strings over A.
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
The reason is to add a delay when bruteforcing passwords.
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…
(compare: polkit. Both sides have their point, but I've been annoyed by this standoff a few times).
https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...
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.
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.
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.
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!
I know sudo-rs will likely not allow viewing the password in the short term, but the benefit to being able to have some visual feedback, is that it lets me use a more complex password.
Other example: if I'm on a ssh link with very high latency (ex: on a phone), I might type one character at the time, make sure they register correctly, and continue. If I can't do that, then I'll type the password in a text editor, then copy-paste it into the password prompt.
Did you wind up sticking with Windows (or Mac) for a long time after this? How long until you tried again?
I value ctrl+U a lot more for password prompts than the visual feedback, it's even used by GUI on Linux.
Not showing feedback on user input is objectively confusing for inexperienced users.
Is it usable now? Do all utilities support all of GNU's features (or most)?
There is a list of open items here, it's looking pretty good tbh: https://github.com/orgs/uutils/projects/1
