The crazier part is Ubuntu using a pre-1.0 software suite instead of software that has been around for decades. The switch to Rust coreutils is far too early.
Do you have some data to back that up? Because I doubt it’s literally 0. I make this point because we shouldn’t talk about absolutes when discussing security.
Fo example, Knowing a password length does make it easier to crack a password. So it’s not strictly “security theatre”.
So the real question isn’t whether it has any security benefit; it’s more is the convenience greater than the risk it introduces.
Framing it like this is important because for technical users like us on HN, we’d obviously mostly say the convenience is negligible and thus are more focused on the security aspect of the change.
But for the average Desktop Ubuntu user, that convenience aspect is more pronounced.
This is why you’re going to see people argue against this change on HN. Simply put, different people have different risk appetites.
The SHA256 hash of a 6-symbol diceware password, where each symbol has its first letter capitalized and the rest lowercase, with 1! appended for compliance with misguided composition rules is 540b5417b5ecb522715fd4bb30f412912038900bd4ba949ea6130c8cb3c16012. There are 37 octets in the password. You know the length. You know the composition rules. You have an unsalted hash. It's only 77 or so bits of entropy. Get cracking, I'll wait.
Typically they’re between 8 and 12 characters. Usually contain dictionary terms, with the first character capitalised and a numeric value at the end with an exclamation mark.
If you know a little bit of information about the individual (which you likely will if you’re in a position to shoulder surf) then you can easily guess at personal details that individual might use (kids names, favourite movie, sports team, that kind of stuff) which also helps narrow the search field too.
Now I’m not saying that this will apply for everyone. But you can see how knowing the password length combined with another piece of information suddenly increases the statistical probability of cracking some passwords.
And this comes back to my earlier point about how security isn’t about absolutes. It’s about probabilities and risk. So there isn’t going to be a universal truth about whether this decision is correct for everyone or not.
You also keep ignoring the fact that anyone who has access to see the length of your input in a shell has access to MUCH more useful information by watching/listening to you type.
Bottom line is that there is no realistic security loss from this, except for the most extreme contrived scenarios. While sure, this is not the best choice for 100% of users, it's still the best choice for 99.99999% of them, so it really doesn't bear discussion.
No. That’s you adding tone that wasn’t there.
> In reality, it's the almost universal norm, with Unixy terminal being the only place that does anything else. When you log into your UI (on Linux, Mac, and Windows), when you access your bank website, when you go to an ATM, when you log into your email account, and so many other places - all use a normal password input that echoes some character for every input.
Which is exactly why I talked about the audience of the security policies and not the technology ;)
It’s the risk appetite of the users that matter more here than the technology.
> You also keep ignoring the fact that anyone who has access to see the length of your input in a shell has access to MUCH more useful information by watching/listening to you type.
I didn’t ignore that. I just didn’t address it because there are a plethora of problems with key strokes and didn’t want to get drawn into a debate about that specifically. But since you asked:
1. They’re not always audible. Not everyone owns a mechanical keyboard ;)
2. backspace, ctrl+d and so on will be keystrokes that delete some or all of the password characters.
3. tab and enter are also keystrokes but also aren’t password characters
4. People are generally worse at counting sounds than counting sequences of visual clues
5. You might be watching someone on video rather than shoulder surfing so key sounds are unavailable
6. Other people might by typing in the vicinity and picking out one typist from another is exceptionally difficult vs reading dots on a screen
7. just because one thing exists it doesn’t automatically mean everything else has no value too
I could go on. But key sounds aren’t as big a giveaway as some on here would like to claim. And they’re definitely not on a par with dots on a screen.
However, if your security model is that even the key sounds are a risk then you / your organisation should be looking a passwordless systems like certificate-based logins.
So again, notice here that I’m not talking in absolute terms but instead discussing risks and their countermeasures.
> Bottom line is that there is no realistic security loss from this, except for the most extreme contrived scenarios. While sure, this is not the best choice for 100% of users, it's still the best choice for 99.99999% of them, so it really doesn't bear discussion.
Except you are discussing it and ended up making the same point I was but expressing it like a counter argument. It would have been a whole lot easier if you’d just said “I agree” but c'est la vie.
How about all the daemons that double log or double timestamp on systemd machines?
I value ctrl+U a lot more for password prompts than the visual feedback, it's even used by GUI on Linux.
The security argument is a red herring. It was originally built with no echo because it was easier to turn echo on and off than to echo asterisks. Not for security.
One implies the other. You turn echo off. Then you write asterisks.
> Not for security.
Consider the case of copy and pasting parts of your terminal to build instructions or to share something like a bug report. Or screen sharing in general. You are then leaking the length of your password. This isn't necessarily disastrous for most use cases but it is a negative security attribute.
This indeed reduces the search domain by many orders of magnitude, i.e. by more than an order of magnitude for each character that you now know that it is not used by the password.
Knowing the length of the password does not matter only in antediluvian systems, which had severe restrictions on the length of a password, so you already knew that the password is no longer than, e.g., 8 characters.
Isn't it 10%?
If you know that a password is no longer than, e.g., 10 characters, that narrows down the search domain by many, many orders of magnitude, in comparison with the case when you did not know this and you had to assume that the password could have been, e.g. 18 characters long.
If you test the possible passwords in increasing length, then knowing the length would not shorten much the search, but not knowing the length may prevent an attempt to search the password by brute force, as such an attempt would fail for longer passwords, so it is not worthwhile to do unless success is expected.
With modern hashing schemes, which require both a lot of time and a lot of memory for each tested password, even one extra character in the password can make the difference between a password that can be cracked in a useful time and one that would take too much time to crack, so knowing the length can be very important for the decision of an attacker of trying the exhaustive search approach.
Knowing the length is less important only for the users who are expected to choose easy to guess passwords, as there are much less of those than the possible random passwords.
I generally use a (unique) 50-ish character passphrase anywhere I need to actually type it myself (and 64-character completely random ones elsewhere) and before this change, the passwords on my linux machines were shorter than that because it was impossible to spot/fix typos.
That's not how it works. Sudo turns off echo but otherwise keeps the terminal in it's normal cooked canonocal mode, meaning sudo only sees what you've entered after you hit enter. To print asteriks as you type requires putting the terminal in raw mode, which has the addition consequence of needing to implement shit like backspace yourself. Still a UX win worth doing, but it's pretty clear that skipping that and just disabling echo is an easier lazier implementation.
I still doubt the claim the scheme employed by sudo was done because it "was easier."
Because to hell with UX when it comes to security. Knowing the exact length of a password absolutely makes it significantly less secure, and knowing the timing of the keystrokes doubly so.
But SUDO is the one bastion where it is absolutely essential to not offer hiding keystrokes as an obscure config option, but enable for everyone and their mother?
I don’t think you have any idea how wrong you are.
So hide the first one as well? But also, that's not true, not all terminal passwords are for local machine
> Confusing — appears frozen
So make it appear flashing? Still doesn't need to reveal length
These servers I had an account setup too were, from what I observed, partially linked with the authentication mechanism used by the VPN and IAM services. Like they'd have this mandatory password reset process and sometimes sudo was set to that new password, other times it was whatever was the old one. Couple that with the high latency connection and password authentication was horrible. You would never know if you mistyped something, or the password itself was incorrect or the password you pasted went through or got double pasted.
I think this is a great addition, but only if it leads to redhat adopting it which is what they were running on their VMs.
But you should not type sudo passwords on remote machine. Instead setup your machinr to have nopassword for special sdmin account and enable pubkey only authentication.
I personally use the pam ssh agent module for this, that way you can use agent forwarding with sudo.
If you are on a high latency ssh connection and your password does not register, you most likely mistyped it.
The passwords get updated irregularly with the org IAM so you aren't sure what the password even is. Pasting doesn't work reliably sometimes, if you're on windows you need to right click to paste in terminals, sometimes a shortcut works. Neither gives me any feedback as to what event was ever registered though.
All the movement commands I know work the same in the terminal on a default install of macOS as it does in the terminal on various Linux distros I use.
Ctrl+A to go to beginning of line
Ctrl+E to go to end of line
Esc, B to jump cursor one word backwards
Esc, F to jump cursor one word forward
Ctrl+W to delete backwards until beginning of word
And so on
Both in current versions of macOS where zsh is the default shell, and in older versions of macOS where bash was the default shell.
Am I misunderstanding what you are referring to by shell motions?
I forgot about this since I started NixOS/home-manager everywhere.
But yeh, never thought this was a problem anyone else delt with. My passwords are all a variant of my on "master password" and sometimes forget which session I'm in so trying to save keystrokes, count backward to where I think the cursor should be.
Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?
Early switching computer systems that had user accounts at Bell also didn't echo back for passwords as some terminals were mixed-duplex, from what I've gleaned in the very odd corners of ESS systems. I suspect the idea is that the model they were working from were touchtone telephones and rotary phones, so numeric passcodes were the standard, and you heard & saw those already? Less noise on paper tapes? The possible list of options goes on and on.
Bell Labs was... Different than your average office or telco environment, I should add.
But that's a swag at best today, without knowing the people that worked on it.
i feel this in my bones.
does anybody know what level this change happens on? is this change going to affect ubuntu desktop users on any system they ssh into, or will it affect all users of a ubuntu server who have ssh'd in?
One thing people are really, really good at is detecting others near them, because it was essential for not getting eaten back in the day. So the chances of (a) someone wanting to shoulder-surf (b) being close enough to do so and (c) getting away with it are essentially zero. It was a security measure that made sense in 1973 when you were on a model 33 leaving a printed record in a machine room with a dozen other people, but has been completely nonsensical for several decades.
Which is probably why it invokes so much irrational religious fervor.
In any case, I don't understand the issue. TCP is "reliable" so it's not like you'll get dropped keystrokes. Just type the password and hit enter, and the entire string will go through when it goes through
Instead of doing this, Ubuntu is just using a Rust rewrite of sudo. Some things really never change.
You'd think by now they'd have learned, but apparently not.
Yes, it means going in a wrong direction sometimes as well: that's why it takes courage — success ain't guaranteed and you might be mocked or ridiculed when you fail.
Still, Ubuntu got from zero to most-used Linux distribution on desktops and servers with much smaller investment than the incumbents who are sometimes only following (like Red Hat).
So perhaps they also did a few things right?
(This discussion is rooted in one of those decisions too: Ubuntu was the first to standardize on sudo and no root account on the desktop, at least of mainstream distributions)
Nobody picked Ubuntu because of Mir, or Compiz, or Upstart(or snaps, while we're on the topic). They were obvious errors. That it's popular doesn't negate that fact.
That is an urban myth relayed by people who weren't even using Ubuntu in its early days.
Other distros were as easy to install as Ubuntu even before Ubuntu was founded. Besides Ubuntu was using the then experimental debian installer you could already use with a regular debian. They just shipped it on the default CD image earlier than debian did.
What they did to be on top was using Mark shuttleworth's money to ship an insane amount of free install CDs to anyone asking for them which meant that for a small period of time, when most people were on dial up internet ISDN and shitty ADSL, Ubuntu went suddently to be the number one distro installed. A friend, family member or coworker was curious about Linux? You'd hand him one of the fifty Ubuntu CDs you had lying around. I know I was one of those handing out CDs left and right. It was a time when to get an install CD without broadband you'd have to buy a magazine, and you didn't get to choose which distro was featured each month, a book or a boxset (not available everywhere). Later all those many early ubuntu adopters became ubuntu evangelists.
But bar a few exceptions like slackware, debian with the default vanilla installer or gentoo, there was nothing particular about the ubuntu install experience compared to other distros. Mandrake, Corel Linux ans Xandrows for example provided super easy install experience even before Ubuntu became a thing.
With a very slim team (I am guessing 15-30 in the first couple of years), they picked Python as the go to language and invested heavily in development tooling making it possible for them to innovate and pivot quickly. Yes, they grew to a mid size company of 500-1000 over time, but also expanded into many different areas.
Perhaps one can also make a case for them effectively starting and killing a number of projects akin to Google, except they usually made them open source, and some live on as volunteer efforts (eg. ubuntu touch).
Never messed with Corel as it wasn't around long, so can't speak for that one.
Focusing more on say, 2005ish, can you think of other examples?
Knoppix kind of led the way in 2000 so it is not surprising that Mandrake didn't have one yet but 5 years later it was already much more common. Some had separate isos for live or install though.
What Mandrake/Mandriva fell massively was in the branding department. All that mage related imagery made it look like a product for young kids and I am pretty sure that distro wasn't really taken seriously for this very reason.
Mir/Compiz/Snaps came much-much later (snaps are as much a mistake as flatpak is: they make sense, but are notoriously expensive to make; Unity was a better UX than Gnome Shell 3, but it did not pay...).
However, none of this explains Ubuntu's penetration on cloud servers.
Canonical was actually solving exactly the same problems Red Hat was, just with much lower investment. Their wins made them dominant, their losses still allowed them to pivot to new de facto standards (like systemd too).
No. Suffering is the crucial part of virtue signaling, so bugs in slop rewrites are a feature, not a bug.
echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee "/etc/sudoers.d/$USER"; sudo chmod 0600 "/etc/sudoers.d/$USER"
sudo mkdir -p /etc/polkit-1/rules.d
echo 'polkit.addRule(function(action, subject) { if (subject.isInGroup("sudo") || subject.isInGroup("wheel")) { return polkit.Result.YES; }});' | sudo tee /etc/polkit-1/rules.d/00-nopasswd.rulesWithout knowing more, creating a transient unit just to run a single shell command seems quite roundabout.
Devs are are missing the point with linux on phone. Get the point part working first lol so that people have some incentive to carry the damned thing. Apps come later
This eliminates the need to do the start manually when you login, but like after a manual start you can stop the GUI session, falling back into a console window, and then you can restart the GUI if needed.
I prefer this variant and I find it simpler than having any of the programs used for a GUI login, which have no advantage over the traditional login.
> That way you can be certain whether or not you entered a character
They can also count the number of keystrokes they heard.
I've seen this demonstrated, using "Cherry" type keyswitches, with about a 75% success rate.
I also knew an old guy who could tell what an ASR33 or Creed teleprinter was printing just by the sound, with "good enough" accuracy, and copy RTTY by ear with "good enough" accuracy.
He didn't really talk about his time in the Royal Signals in the 50s and 60s very much.
You can no longer filter out power users of computers based on their choice of OS alone. :D
Of course, once you do understand that it's just a password prompt, it's great. Completely confuses the hell out of any shoulder surfers, who will for sure think it's a confusing puzzle, and eventually they will get rate limited.
^1: Example of it in use: https://www.youtube.com/watch?v=FvT44BSp3Uc
What's the benefit of having a random character from a random set, instead of just a random character?
I think if I was new to Linux that would confuse the life out of me :)
I thought that was kinda clever; it gives you feedback when your keystrokes are recognized, but it's just enough confusion to keep a shoulder surfer from easily being able to tell the length of your password unless you're hunt-and-pecking every single letter.
I'm guessing that wasn't in the threat model at the time.
(# available characters) ^ (password length)
to
(# available characters) * (password length).
If you were patient you could crack someone's passwords by hand.
What this means is that you can now reduce your search space to approximately 16^9 passwords instead of 64^9 passwords. Which is probably very helpful if you have stolen the password hash, but not if you have to guess it by entering the password manually.
"That way you can be certain..." absolutely not.
Presumably they’re capable of buying a $5 wrench to physically use against you.
Or just plugging a device into your laptop while you’re not looking and stealing all your session state for browsers.
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/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.
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.
And I just removed the delay using my method. Perhaps try checking something yourself?
> 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
> Perhaps try checking something yourself?
I have. You haven't.
printf 'hunter2\0' | unix_chkpwd yourusername nullok; echo $?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).
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!
The reason is to add a delay when bruteforcing passwords.
In the modern world there is no plausible scenario where this would compromise a password that wouldn't otherwise also be compromised with equivalent effort.
Or, we could just look at the keyboard as they type and gain a lot more information.
In an absolute sense not showing anything is safer. But it never really matters and just acts as a paper cut for all.
> When trained on keystrokes recorded by a nearby phone, the classifier achieved an accuracy of 95%, the highest accuracy seen without the use of a language model. When trained on keystrokes recorded using the video-conferencing software Zoom, an accuracy of 93% was achieved, a new best for the medium.
Have you ever watched a fast touch typist, someone that does over 100 words per minute? Someone who might be using an keyboard layout that you're not familiar with? When the full password is entered in less than a second it can be very difficult to discern what they typed unless you're actually recording with video.
But sure, if you're watching someone who types with one finger. Yes, I can see that.
Besides, observe that several times and you might get close. Look at the stars several times and learn nothing beyond what you learned the first time.
This whole type of attack hinges on the user using weak passwords with predictable elements in any case.
Only if length is known. Which is true now. So it opens the gates to try passwords of specific known length.
For ascii at 95 printable chars you get 0.9894736842. Makes intuitive sense as the "weight" of each digit increases, taking away a digit matters less to the total combos.
Maybe I'll start using one Japanese Kanji to confuse would be hackers! They could spend hours trying to brute force it while wondering why they can't crack my one letter password they saw in my terminal prompt. ;)
At the very least, all GNU tools put a lot of focus on localization support, and I hope sudo-rs is the same.
Hmmm, hopefully sudo-rs respects LC* env vars. I recall reading a few years back that some Rust Unix tools skipped that and won big on benchmarks until folks realized they weren’t handling NC localization properly.
In the early days we all shared computers. People would often stand behind you waiting to use it. It might even not have a screen, just a teletype, so there would be a hard copy of everything you entered. We probably didn't have account lockout controls either. Knowing the length of a password (which did not tend to be long) could be a critical bit of info to reduce a brute force attack.
Nowadays, not so much I think. And if you are paranoid about it, you can still set it back to the silent behaviour.
Not sure about that. I'm no expert but for high risk scenarios one might have to worry about binoculars from the building opposite your window, power line monitoring, and timing attacks. All scenarios where the attacker cannot see your hands/keyboard.
This reminds me. Linux was already a fossil, except for some niches, but now in the age of AI, the fact that code can't be updated at will (and instead has to go through some medieval social process) is fatal. Soon the age will be here where we generate the necessary OS features on the fly. No more compatibility layers, no more endless abstractions, no more binaries to distribute, no more copyright, no need to worry about how "the others" use their systems, no more bike shedding. Instead, let the system manage itself, it knows best. We'll get endless customization without the ballast.
It's time to set software free from the social enclosures we built around it.
⣾, ⣽, ⣻, ⢿, ⡿, ⣟, ⣯, ⣷
apt install sudo-ws
apt remove coreutils-from-uutils --allow-remove-essential
However it is pretty obvious at this point that Ubuntu will absolutely remove those from one of the future releases because availability of real sudo and coreutils is detrimental to the virtue signaling they are engaging in.
After being a lifetime Ubuntu user I have moved to Debian across almost all of my production.
What?!
2026 minus 46 is 1980. There was no Linux, at all, in 1980.
Someone is quite confused.
They also repeatedly talk about a 'half century' of Linux terminals in other parts of the article. This site seems to cater to Linux specifically in many respects, so it's quite reasonable to call them out on super-simple stuff.
Alternatively, if it's confusing, you shouldn't be doing whatever it is you're doing with sudo because you copy pasted a command from God knows where with zero understanding.
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.
I doubt this is a super common threat but I would expect it to be already applied by spies or "Jia Tan" like employees.
Did you wind up sticking with Windows (or Mac) for a long time after this? How long until you tried again?
A space with a cursor instead of an asterisk would make it harder to count the Chars
Adding a random 1 to 3 output chars instead of one would obfuscate this even more.
A delayed output could make you submit the password prompt before showing anything.
A single asterisk that switches back to space after 250ms inactivity may even be better.
I don't know, but somehow this feels underthought even if it probably is not. Simple is probably the best approach
Users expect to see exactly 1 new char (either the key pressed or an asterix) when they type something. Seeing up to three chars appearing or disappearing after some time imho is worse than what we have today.
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.
The expectation with sudo is silent passwords.
And yes, it remember how many it echoes so backspace works correctly.
Whimsy, and character.
Used to be that everything was trying to look different. Now it seems like everything is trying to look the same.
2) It's amazing the amount of (pseudo-) nostalgia that millenials, gen-Z and younger have for 90s-2010s computer aesthetic. The Amazing Digital Circus comes to mind for example
I'm sure someone things this is a good idea, but I do not, and nobody cares what I think. But I come from being a long-time coder who's always been a terrible typist and can't depend on "touch typing" and have to actually look at things, like the keys, and the screen. And handicapped by going blind in one eye, and having arguments with eye doctors who say "get used to it and switch to audio books" and needing 14-point boldface fonts for everything.
It feels like dumbing down the cli.
But I don't know if this is an elder millenial walk up hill in the snow both ways kind of thing though.
Am I alone in this?
As for security: 'shoulder surfing' may not be as much of a concern, but watching a livestream or presentation of someone who uses sudo will now expose the password length over the internet (and it's recorded for posterity, so all the hackers can find it later!). They've just introduced a new vulnerability to the remote world.
Besides, I can just amplify their stream to hear their keypresses.
You actually believe that every person in the world who shares their screen is aware of computer security best practices? Or are we only limiting this generalization to every one of the millions of YouTube/Twitch livestreamers?
> I can just amplify their stream to hear their keypresses.
Maybe if they have Cherry MX Blues? A normal keyboard would not get picked up by modern apps' recording noise suppression (the filters are designed to eliminate the sound rather than merely lower volume).
Also, I think the vulnerability of knowing that someone's password is exactly 19 characters long is low enough to be worth the tradeoff. Especially since someone on a livestream can also figure that out by listening for the keypresses.
It helps 99% of the user base and the security risk seems negligible.
In your specific example livestreams usually have audio so the length is already public.
Changing the default is the point, because people often just don't look into whether it's possible to configure things. They might not even get the idea that the asterisk feedback could be possible, or useful, until it's shown to them.
> How is exposing length of a password a vulnerability?
You're arguing exactly the point.. knowing the length of a password is helpful in cracking it. We all agree short is bad. Depending on your threat model, you (hopefully) don't use passwords as the only verification very many places - perhaps to unlock stronger secrets (ssh keys, an account without local login that can only connect with a certificate). You'd still rather a shoulder surfer doesn't know how many characters you pressed.
So yes, sure, technically there is an effect, but it's such a small effect, and only for people that should change their damn passwords already, that it's worth making the change for the improved UX.
If I pick a random 1-5 character password out of the pool of possibilities, it's very very likely to be 5 characters, and letting you know it's not 1-4 characters does pretty much nothing to help you crack it.
If I'm acting reasonably, I don't randomize the length, I pick a length long enough for the amount of security I want, and in that situation telling you the exact length reduces that security by much less than one bit.
Also what demos are you doing that require sudo access to your local machine? That’s already pretty niche.
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
I always thought it was annoying anyway.
Not showing feedback on user input is objectively confusing for inexperienced users.
I don't really want to just disable passwords. I recall that causing technical pains. And this is a desktop PC in my home office and I'm just generally okay with the associated security risks.
You could probably throw together a quick PAM module that scans for your phone's presence. But, aside from the security/spoofing risks, Bluetooth scanning can take half a minute even when you have the device set to be discoverable so you may be faster off typing in your password.
Alternatively, you could just disable the password prompt for sudo if you make sure to always lock your screen. Or not even that if you don't have disk encryption enabled, as anyone with malicious intent can do anything to an unencrypted laptop anyway.
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.
Your argument therefore doesn't apply in this context.
This wasn't someone seeing Chesterton's fence and deciding to knock it down thoughtlessly. This is a change that someone can in fact think all the way through and say "yeah, this should be changed, it's an improvement and doesn't cause any meaningful reduction in security".
Or think of TEMPEST attacks
`sudo` and `login` are I think the only two tools I use that don’t provide any feedback.
Otherwise my entire life is behind a password database that lets me see my password in plaintext and otherwise shows the length of it as it’s typed. KeepassXC.
If knowing how the length of your password makes it easy to crack you probably have other problems
So yes, "easier", technically. But not in any meaningful way.
Conversely, making people more comfortable with security measures may well improve security; for instance, some people will have an easier time typing in longer and more complex passwords thanks to password feedback.
Usability is often a security feature.
Knowing the length narrows down the search space some, but a meaningfully long password basically makes that knowledge useless, and again, it’s only useful if the approach they take is to try to physically possess your computer or obtain an encrypted backup.
A far more likely effort is going to be a spear fishing email, especially since if they have physical access to you they probably know a lot about you, and what services to spoof to get you to give them passwords, and so on.
> For a time, there was rich pickings in applications that accepted passwords in unbuffered mode. Many of them doing it so that they could echo "*" symbols, character by character, as the user typed. That simple feature looks cool, and does give the user feedback ... but would leak the keystroke rate, which is the last thing you want on password entry.
This was in response to keystroke timing defense on SSH. Does this feature still come with the risk of leaking keystroke timing to an attacker with recent OpenSSH/Dropbear versions? If so, it might be wise to keep it disabled on servers.
> Specifies whether ssh(1) should try to obscure inter-keystroke timings from passive observers of network traffic. If enabled, then for interactive sessions, ssh(1) will send keystrokes at fixed intervals of a few tens of milliseconds and will send fake keystroke packets for some time after typing ceases. The argument to this keyword must be yes, no or an interval specifier of the form interval:milliseconds (e.g. interval:80 for 80 milliseconds). The default is to obscure keystrokes using a 20ms packet interval. Note that smaller intervals will result in higher fake keystroke packet rates.
Although that's on the client-side, if the server responds with a "*" symbol for each keystroke it might be possible to reconstruct password length from network traffic.
Combine that with a flaky keyboard (say from a single grain of dust where it shouldn’t be) and you get a very annoying login experience. Over and over…
If you have Capslock set to change your keyboard language, and your computer locks with Capslock enabled, you literally can't type lowercase letters of your password. Capslock doesn't work, shift doesn't make it go lowercase - you literally just have to reboot to get back in.
How would your computer lock with capslock enabled? I.e. if capslock on that computer is set to change keyboard language?
I.e. configure the custom binding to also work on lock screen. Karabiner supports this I think.
Alternatively, rebind caps lock with a custom binding and not os settings (i.e. don’t rebind keys in both a custom tool and the OS). Then, if custom bindings don’t work on lock screen, you get the default, working keyboard on lock screen.
Yes
I was much too young to use it myself, but I saw other people log in and it was amazing.
The glyphs denoting hidden password characters changed on every keystroke to indicate you were typing. And IIRC, they were cool characters like Egyptian hieroglyphs too. (Presumably this wasn't some hash of your actual password - that would actually be dumb. I do think it indicated password length, which could give away info, but it's also useful for the user.)
Edit: this is not exactly as I remember, but it might be the same system: https://security.stackexchange.com/questions/41247/changing-...
If that's how it was implemented, then that's not great.
IIRC, originally it echoed one glyph per character typed, but later it definitely echoed 1 to 3 glyphs at random so it wouldn't leak your password length.
The password thing was pretty cool, but it's literally the only good thing about Lotus Notes, which was the most archaic and primitive piece of commercial GUI software I've ever used in 45 years of software experience. I last used it in 2003, and even then its UI was so archaic, it didn't adhere to behaviors (like keybindings, and other basic UI elements) that had been standard since the 80s.
Absolute garbage software.
I use Open Core Legacy Patcher (OCLP) to run modern macOS on old Intel macs. The first time the computer boots after an upgrade (e.g. Sequoia 15.7.3 to 15.7.4), it is slow as a dog. Because the macOS upgrade clobbers all the OCLP driver patches.
By "slow", I mean each keystroke on the login screen takes about 20-30 seconds for the corresponding bullet to appear in the password box.
The login screen displays 13 bullets. My password is 18 characters long. (Scammers, don't get excited, it's a unique password that's not used anywhere else on the Internet...) So after 13 characters, I had no idea if the computer was actually working.
It seemed like there is a 6-8 character keyboard buffer limit. Or maybe I typed in my 18-character password wrong multiple times. I don't know. I would type 2 characters, then walk away, come back, then type 2-3 more characters. It took me about 4-5 attempts over 30 minutes to log in. Then I applied the OCLP patches and everything worked perfectly after that.
I would've thought it would've been a simple carry over from before terminals were glass. Like, yeah, I get up from a glass terminal and someone else goes to use it, but wouldn't the scrollback be cleared when I log out? But silent logins from before glass terminals makes a ton of sense; it would literally print your typed characters on a real, physical medium. having
login: cool_user
password: hunter2
I dunno, I take them at their word but if you had asked me why password prompts in the terminal don't echo, I would've guessed it was a carry-over from the days of real teletype terminals.
I suppose you could do character buffering and quickly change to normal, print an asterisk, and back to silent mode in one write. But likely there's always some kind of edge case where things work differently. It's not difficult to disable so this may be better for the 99% and the 1% can change it back.
It's on brand for Ubuntu, though. They've been looking for an audience that is not me for a very long time. I sometimes worry about Debian's resistance to social pressure, though. It seems that Debian doesn't fall for marketing or corporate pressure, but they sometimes fall when they are surrounded by people who have fallen for marketing or corporate pressure.
The correct change would be leave the default and put in the visudo file for easy uncommenting. The "developers opinion" is flat wrong.
# uncomment below to see *s when typing passwords # Defaults pwfeedback
All of the dev thinking on the matter is based on narrow use-cased "if you're on a a host where login to a login screen and people can see you... "
When users connect via ssh keys to production hosts and type sudo passwords, I do not one iota of potential security benefit lost.
- If it's so short that the knowledge of the length makes bruteforcing noticeably faster, the password is so short that the total length taken would be very short regardless.
- In all other cases, it removes such a small fraction of time needed (on the scale of removing one age-of-the-universe from a process that would otherwise take thousands of ages-of-the-universe) that it doesn't change any infeasible timescale to a feasible one.
So either the information isn't needed, or it won't help. So not a security decrease.
Though I guess the broader context is if the attacker has "shoulder-level access" you probably have bigger things to worry about ;)
The default entry on xsecurelock[^0] shows a character jumping on a line between keystrokes, which works well on giving key press feedback while visibly obfuscating password length,
________|_______________________ // after pressing a key it'd move around,
___________________|____________
# /etc/sudoers
Defaults !pwfeedback
security.sudo-rs.extraConfig = ''
# NixOS extraConfig
# ===========
Defaults !pwfeedback
'';
It might matter a bit more for dictionary-based attacks (you don't have to bother hashing dictionary permutations that don't match the expected length) but I still suspect it doesn't save you much.
For opportunistic attacks, this could help you identify those with short passwords and only attack them. This is a factor of N speedup where N is the pool of people you are interested in attacking.
On some systems I've gone as far as removing that delay. It's either that, reusing the same password everywhere, or losing my fucking mind. This should fix that wonderfully.
That said, with any feedback that confirms my key was pressed I can pretty much always correct a mistake using backspace without trouble (with backspace also having visual feedback).
It doesn't make sense to show the exact amount of characters. It just leaks the password length.
Edit: and the article clearly states, incorrectly, "That behaviour survived — untouched — through nearly half a century of Linux distributions."
----
For KDE:
sudo vim /etc/sddm.conf.d/hide-password.conf
[Greeter]
ShowPasswordEcho=false
----
For `sudo`:
sudo vim /etc/sudoers.d/password-no-visual-echo
Defaults !pwfeedback
For GNOME, you have to modify `unlockDialog.js`
sudo vim /usr/share/gnome-shell/js/ui/unlockDialog.js
this._passwordEntry.clutter_text.set_password_char('');
Opinionated security tools maintainers rarely get it right.
Uniqueness is the number one thing that matters. The modal attack is a remote credential stuffing attack by someone trying millions of email/password combinations from a database.
Seriously, what does sudo even protect anymore, and when are you typing it with someone looking over your shoulder?
If you have a Linux or Mac desktop, the login password prompt has the same design choice regarding showing characters and is much more likely to actually be used in front of someone. In modern Linux development, you shouldn’t be using sudo most of the time, and on ssh machines, you shouldn’t have a sudo password.
And even if someone did see it then they’d have to get physical access to your machine. If someone has easy physical access to your machine and wishes you harm, then knowing the length of your desktop login is probably the least of your worries.
The other side of that coin: If you see a password prompt on someone's screen, turn your back.
To reduce the length exposure, the software could randomly show multiple asterisks per key-stroke. I think Lotus Notes did this. Of course, this may lead to people suspecting keybounce.
I've successfully shoulder-surfed someone to discover their password (in response to a sudo prompt) by watching their hands and fingers. So if the person is close enough, having echoed stars or not makes no difference. It was long password too, but contained two whole lowercase words.
Reverse the logic and make a “sudo_h” script which hides the password entry for those rare times you need it.
Truly, when anything in Slashdot News (delete delete) "HaCk3R Newz" has more than about 300 comments, I know it will be a merry-go-round of imbeciles regurgitating nonsense. A moronic choir of nobodies singing the same note. This one didn't disappoint.