Rendered at 07:12:48 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
written-beyond 1 days ago [-]
The number of times I've been stuck wondering if my keystrokes are registering properly for a sudo prompt over a high latency ssh connection.
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.
ornornor 14 hours ago [-]
Around 2004 someone gave me Linux CDs (I think it was mandrake?) that I tried to install. And I got stuck at the password input part of the setup, I thought it didn’t work and went back to windows. I didn’t start using Linux until 13 years later… I think I’d have switched much earlier if not for that weird UI decision.
tankenmate 13 hours ago [-]
This decision long predates Linux. It's been a staple back to the earliest days of Unix; and it isn't a weird decision if you take into consideration of multi user systems in office environments that have non trivial security considerations (for example telecoms companies), which is exactly where Unix came from.
wartywhoa23 12 hours ago [-]
Well, if leaking the length of the password is such a big deal, why not just use a reasonably long password?
Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?
tankenmate 11 hours ago [-]
Again looking back at the history of Unix, it used a 56 bit variant of DES encryption that used the user's password as the key. So only the first 8 characters of the password were used and the rest was silently unused, for example "password" and "password123" would have been the same password on early Unix. And although most BSDs and Linuxes moved in the mid 90s to PAM (and hence md5, etc) most SVR4s didn't move until late in the 90s. And at the other end, DES crypt() made its way into Unix in some v6s (~1977) and became widely available in the release of v7 Unix. So 8 character passwords were a thing for about 20 years.
LorenDB 5 hours ago [-]
Or listening to the number of keystrokes (although you can add random characters and then backspace to help mitigate this).
sandworm101 39 minutes ago [-]
It was also a time when not every employee had their own computer. It was very normal for pairs or groups of people to all huddle around a machine while working through a problem. It was also common to have someone behind you waiting for their "turn" to use the machine for their project.
mbesto 14 hours ago [-]
The number of times i realized half way that I probably posted the wrong password and so I vigorously type the 'delete' key to reset the input is too damn high
larsbrinkhoff 14 hours ago [-]
Just type Control-U once.
eptcyka 14 hours ago [-]
The Just in that sentence is wholly unjustified. There are plenty of cli/tui/console/shell shortcuts that are incredibly useful, yet they are wholly undiscoverable and do not work cross-platform, e.g. shell motions between macOS and reasonable OSes.
QuantumNomad_ 13 hours ago [-]
> shell motions between macOS and reasonable OSes
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?
eptcyka 12 hours ago [-]
Yea, but ctrl + arrows to move cursor between ‘words’ don’t work, especially sad when SSH’ing in from linux. It works fine when using terminal on macOS - you just use command + arrows.
mathfailure 7 hours ago [-]
Works fine for me. Configure your shell.
malfist 9 hours ago [-]
What happens when you press home or end?
int_19h 14 minutes ago [-]
In iTerm at least it goes to the beginning or end of current line.
macintux 5 hours ago [-]
The number of times I’ve attempted to use Ctrl-U in a Python shell only to discover it doesn’t work…
fer 11 hours ago [-]
> e.g. shell motions between macOS and reasonable OSes.
I forgot about this since I started NixOS/home-manager everywhere.
queenkjuul 5 hours ago [-]
I only know this because of xkcd
hilliardfarmer 14 hours ago [-]
Get out of my head, lol :)
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.
amarant 12 hours ago [-]
The number of times I've posted my sudo password in a random slack channel instead of my terminal is not very high, but too damn high nonetheless
antod 11 hours ago [-]
Start your password with a forward slash :)
lxgr 11 hours ago [-]
The trick is to use a plausible Slack message as your sudo password :)
Matheus28 4 hours ago [-]
“I quit!” Even includes a special character
doubled112 4 hours ago [-]
"I, uhh, need your thoughts." should have fewer consequences AND be more secure.
augusto-moura 22 hours ago [-]
Had problems with faulty keyboards in the past too, never to be sure which keys were I pressed I had to type the password in a text file (much more insecure) and then paste it on the prompt. Of course this was never done in front of anyone, shoulder surfing was never an issue to begin with.
notatoad 5 hours ago [-]
>a sudo prompt over a high latency ssh connection
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?
queenkjuul 4 hours ago [-]
It's the sudo binary installed on the host -- if you're SSH'd to a 26.04 host, you'll see stars; if you're running 26.04 and SSH to a different OS, you won't (unless the remote system is also 26.04 or otherwise using rs-sudo)
pseudohadamard 3 hours ago [-]
I wonder if it'll stick though? Some years ago FreeBSD changed their setup so the initial password you set on install was echoed back to you so you could verify that the thing that'll completely lock you out of the system if you get it wrong is correctly set up. The response was total hysteria. Apparently people were setting up their 1U rack-mount servers while riding the No.8 bus and were worried other passengers were looking over their shoulders while they typed in the password. So they backed out of the change after being buried in a mountain of complaints.
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.
crazysim 13 minutes ago [-]
Did that echo the password back on the screen or just asterisks?
ghighi7878 21 hours ago [-]
I agree that this move is good.
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.
written-beyond 21 hours ago [-]
Yeah but am I going to really open another ssh connection just to run an admin specific command. They also didn't provide an admin user, it setup with all of the extra security configurations. You couldn't even `su`
ghighi7878 12 hours ago [-]
I mean nopasswd option of sudo
Wowfunhappy 13 hours ago [-]
Why is it better to have a nopassword admin account when using a machine remotely? The point of SSH is to resist mitm attacks, right? If someone could watch my keystrokes, I think I'd have bigger problems!
tsimionescu 45 minutes ago [-]
This resists scenarios where the machine you are running SSH from is compromised, and has a keylogger or something similar installed. SSH can't protect you from a local attacker (in fact, the SSH client binary itself could be the compromised part).
wolvoleo 14 hours ago [-]
With sudo you can also give people specific access to commands.
I personally use the pam ssh agent module for this, that way you can use agent forwarding with sudo.
ghighi7878 12 hours ago [-]
I did mean nopasswd option of sudo.
johnisgood 14 hours ago [-]
You can tell if you input something or not, based on the blinking cursor, in which case it is not "frozen".
semanticc 14 hours ago [-]
Unless you disable cursor blinking because you find it annoying (like I do).
setopt 12 hours ago [-]
Yeah, disabling cursor blinking is the first configuration I do in any terminal.
written-beyond 11 hours ago [-]
I mean a trivial solution to all of these work around a could have been each keystroke registers a single asterisk that goes away after a delay. You wouldn't reveal the length and you'd had a standard way of informing the user that their keystroke was registered.
znpy 21 hours ago [-]
You could have avoided the worry completely. Ssh goes over tcp that does transport control (literally the “tc” in “tcp”) and this includes retransmission in case of packet loss.
If you are on a high latency ssh connection and your password does not register, you most likely mistyped it.
written-beyond 19 hours ago [-]
I am aware of that but you forgot the other conditions. Keys sometimes don't register, I'm not sure why but I do experience missing keystrokes.
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.
vman81 18 hours ago [-]
Yea, add a VNC jump host and a flaky spice based terminal and there are a bunch of things that can make your input not register properly.
egberts1 9 hours ago [-]
You can opt-in for a "no visual echo" of any character (asterisk or not) for password prompts:
----
For KDE:
sudo vim /etc/sddm.conf.d/hide-password.conf
insert in:
[Greeter]
ShowPasswordEcho=false
then reboot.
----
For `sudo`:
sudo vim /etc/sudoers.d/password-no-visual-echo
Insert/replace `Defaults` with:
Defaults !pwfeedback
----
For GNOME, you have to modify `unlockDialog.js`
sudo vim /usr/share/gnome-shell/js/ui/unlockDialog.js
or in newer version, replace `echo_char` with `null`. Reboot required.
rurban 22 minutes ago [-]
Or just replace sudo-rs with sudo.
Opinionated security tools maintainers rarely get it right.
cozzyd 7 hours ago [-]
Can I change my password char to an emoji?
egberts1 7 hours ago [-]
Only with GNOME
necovek 4 hours ago [-]
The "cinfiguration" for GNOME actually modifies the source code, so if that's the bar, you can do it everywhere. :)
herewulf 2 hours ago [-]
In that case, I'll make mine echo a random number of characters pee key stroke. The feedback is nice but then there are no worries about someone observing password length.
odo1242 56 minutes ago [-]
I mean, Gnome being in JavaScript makes it easier
koolba 12 hours ago [-]
Somebody tell Apple to fix the login screen for MacOS as well. If your password is longer than the incredibly narrow box, you do not get any additional feedback that your characters are being entered.
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…
OsrsNeedsf2P 12 hours ago [-]
Oh my God, the MacOS login screen..
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.
asutekku 6 hours ago [-]
That must be something you have changed, because if I have capslock enabled, it shows the capslock icon in the input field and the key is pressable to disable it for me.
odo1242 2 hours ago [-]
> If you have CapsLock set to change your keyboard language
Yes
mjevans 3 hours ago [-]
Could be an external keyboard state thing.
thih9 10 hours ago [-]
> If you have Capslock set to change your keyboard language, and your computer locks with Capslock enabled
How would your computer lock with capslock enabled? I.e. if capslock on that computer is set to change keyboard language?
EstanislaoStan 10 hours ago [-]
Maybe they're saying the key rebound to serve as capslock doesn't work on the lock screen?
riknos314 7 hours ago [-]
[dead]
bxparks 11 hours ago [-]
I felt this pain yesterday.
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.
leptons 1 hours ago [-]
That's exactly the situation I wanted to avoid with our aging macbook. I knew it would be a hacky mess trying to keep beating that dead horse to get it to run the latest OS. We couldn't update some software that required us to be on the latest version of MacOS (Signal desktop), so the laptop became prematurely obsolete. We bought a Windows PC instead.
echelon 11 hours ago [-]
I'd be even happier if everyone adopted the old school Lotus 1-2-3 password behavior.
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.)
If that's how it was implemented, then that's not great.
ConceptJunkie 8 hours ago [-]
You're thinking of Lotus Notes, a completely different product.
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.
queenkjuul 4 hours ago [-]
Take in this horror: the F500 i got my first job at was using Notes until 2021
Someone should make a joke version that replaces the ***s with comedic passwords or ridiculously bad ones: When you're typing your real password, "iloveyouiloveyou", "12345612345", or "hunter42hunter.." gets printed to the screen.
chuckadams 13 hours ago [-]
Do like Lotus Notes did and have it update a row of literal hieroglyphics on every keystroke.
andai 11 hours ago [-]
This made me think, it seems like there used to be a lot more whimsy in computing. I'd love to see more of that.
Whimsy, and character.
Used to be that everything was trying to look different. Now it seems like everything is trying to look the same.
necovek 4 hours ago [-]
On the contrary, this discussion is how there was no character when you were typing your sudo password in in the olde times, and now there is a full asterisk per every password symbol you put in!
morkalork 11 hours ago [-]
1) It definitely feels like we're out of Cambrian explosion period of experimentation
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
stavros 10 hours ago [-]
While I support this for the humour factor, it does make it much easier for a shoulder surfer to count characters, for whatever that's worth.
the_real_cher 15 hours ago [-]
I would absolutely install this.
dtech 24 hours ago [-]
This is such a good decision. It's one of those things that's incredibly confusing initially, but you get so used to it over the years, I even forgot it was a quirk.
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.
ahofmann 23 hours ago [-]
I also think it is a good decision.
Nevertheless it breaks the workflow of at least one person. My father's Linux password is one character. I didn't knew this when I supported him over screen sharing methods, because I couldn't see it. He told me, so now I know. But the silent prompt protected that fact.
It is still a good decision, an one character password is useless from a security standpoint.
airstrike 14 hours ago [-]
If it breaks the workflow of one person but makes it better for many more, it's likely a worthwhile tradeoff.
dietr1ch 8 hours ago [-]
Just add an option to let holding space keep my feet warm. It only needs a few extra lines that won't change.
wartywhoa23 12 hours ago [-]
How much would unknown password length protect against bruteforcing a 1 character password?
nextlevelwizard 10 hours ago [-]
This has always been an option and your dad can just flip the default back to not show it
zx8080 23 hours ago [-]
> It is still a good decision, an one character password is useless from a security standpoint.
Only if length is known. Which is true now. So it opens the gates to try passwords of specific known length.
ludston 22 hours ago [-]
If you are brute forcing passwords, knowing the length only reduces the number of passwords to try by like 1 hundredth.
elcritch 22 hours ago [-]
Drats, you're right. I thought it'd be worse, but the ratio seems to only depend on the number of letters in your character set: 1/count(letters in alphabet).
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. ;)
dhosek 14 hours ago [-]
I’ve occasionally contemplated using some non-ASCII character like • or š in a password, but have backed off for fear of needing access from a device that doesn’t support input of those characters.
Obscurity4340 19 hours ago [-]
Its funny how a single japanese symbol would be harder to crack than the anglicized name for it
LoganDark 14 hours ago [-]
Do we know if the asterisks count Unicode code points rather than bytes?
Izkata 14 hours ago [-]
Doesn't really matter, the IME shows the input until you confirm which kanji you want.
LoganDark 13 hours ago [-]
When the IME inserts the character, it'll be made up of multiple bytes because of the nature of UTF-8, so it may appear as multiple asterisks regardless.
egeres 22 hours ago [-]
It also give you the possibility of filtering out which ones are worth cracking and which ones not
elcritch 22 hours ago [-]
It could also give useful priors for targeted attacks, "Their password is 5 characters, and their daughters name is also 5 characters, let's try variations of that".
justsomehnguy 12 hours ago [-]
Some system accessible to hackers who can see the length of the password /and/ having a single 5 char password has a security of a key under a doormat.
brnt 23 hours ago [-]
I may or may not use a single char password on a certain machine. This char may or may not be a single space. It may or may not be used in FDE. It's surprising what (OS installers) this breaks.
Freak_NL 23 hours ago [-]
Yes… We're in the same room as the target… Let's look at their screen and see how long their password is.
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.
darkwater 22 hours ago [-]
And just sticking to counting, a not exceptionally well-trained ear could already count how many letters you typed and if you pressed backspace (at least with the double-width backspace, sound is definitely different)
elcritch 22 hours ago [-]
Yeah I recall that there was an attack researchers demonstrated years back of using recordings of typing with an AI model to predict the typed text with some accuracy. Something to do with the timings of letter pairings, among other things.
vova_hn2 13 hours ago [-]
93% - 95% accuracy and it wasn't even a good quality recording
> 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.
Notably, I believe this has to be tuned to each specific environment. The acoustics of your keyboard are going to be different from mine. Which is not much of a barrier, given a long enough session where you can presumably record them typing non password-y things.
SapporoChris 22 hours ago [-]
"Let's look at their screen and see how long their password is." This article is about silent sudo.
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.
Freak_NL 22 hours ago [-]
How is learning only the length of the password better than watching someone type it?
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.
MattPalmer1086 22 hours ago [-]
I tend to agree, and I work in security.
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.
tester756 22 hours ago [-]
On the other hand streaming is way, way more common nowadays.
wpollock 6 hours ago [-]
> 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.
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.
dietr1ch 10 hours ago [-]
I like the idea of showing keystrokes, but I think that a 1:1 entry has arguably better alternatives.
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,
___________________|____________
Also, for anyone looking into preserving this last resort obfuscation behaviour you can do it with,
I've got to say, if you were able to see me typing, you can probably record me doing so, bug my USB keyboard, or buy a $10 wrench. I guess for people streaming it might be worth it? I don't think it's a big enough deal to warrant the fuss around this change though, it's just an ok UX improvement that could be slightly better at retaining the sense of security.
Not giving away the length is mainly an assistance to people with really short passwords. Knowing that someone has a 12 character password doesn't help attackers much, but knowing that someone has a 6 character password would be really useful.
kevincox 8 hours ago [-]
It's still not very useful to hide the length. If you don't know the length and just start guessing with passwords of length 0 it only adds about 1/N extra guesses where N is the alphabet size compared to guessing strictly the right length. So it is a very small savings to know the password length.
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.
aidenn0 8 hours ago [-]
That's only for targeted attacks.
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.
moffkalast 10 hours ago [-]
Actually now that I think about it, showing the entered length is very useful, cause I often find myself entering the wrong password for something else, realizing 2/3 the way through and I have two options: to hold backspace for some random amount of time (usually for not nearly long enough cause there's no feedback as to how many characters remain to delete), or enter the wrong one and wait for the long ass delay to let me do it again.
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.
dietr1ch 9 hours ago [-]
Maybe it works for <=10 character passwords, but it seems to me that if you are counting asterisks in a longer password because you lost track of you input, then you are better off using C-u to clear the password and enter it from scratch.
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).
0xbadcafebee 14 hours ago [-]
They could have just made it an option to enable the new behavior. There was no need to change the default.
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.
post-it 13 hours ago [-]
Someone live streaming is well attuned to the dangers of exposing personal information on screen, and will hesitate before ever typing a password while streaming. They'll either disable this feature or open a root shell before beginning their stream.
Besides, I can just amplify their stream to hear their keypresses.
halapro 13 hours ago [-]
This is really a non-issue, all password fields behave this way, so it's not like this is a new computer behavior. This change only aligns sudo to literally everything else.
0xbadcafebee 10 hours ago [-]
> Someone live streaming is well attuned to the dangers of exposing personal information
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).
post-it 10 hours ago [-]
What I do believe is that every person in the world who arrives at a sudo prompt had previously entered a password into a field that echoed asterisks, and as such is prepared to appropriately conceal their password.
roger_ 13 hours ago [-]
Why no need to make it the default? I’m all for rethinking legacy decisions.
It helps 99% of the user base and the security risk seems negligible.
0xbadcafebee 10 hours ago [-]
Rethinking would imply there was thinking going on. This decision was made on vibes alone.
LinXitoW 8 hours ago [-]
If anything, the people clinging to this snake oil security theater are the ones running on vibes alone.
10 hours ago [-]
jandrese 13 hours ago [-]
I feel like livestreaming is a good example of an unusual situation where one might consider changing defaults that are otherwise good for the majority of users.
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.
pvillano 14 hours ago [-]
An accessibility feature helps more people if is it is on by default.
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.
eapressoandcats 7 hours ago [-]
They’d still need to have access to the device, so it shouldn’t be a problem unless other passwords are the same as your device password.
Also what demos are you doing that require sudo access to your local machine? That’s already pretty niche.
zarzavat 12 hours ago [-]
If your sudo password can be exposed by its length then you need a longer password. Hiding the length is just security theatre.
In your specific example livestreams usually have audio so the length is already public.
safetytrick 11 hours ago [-]
Yes, this mattered when 6 character passwords were common.
boca_honey 13 hours ago [-]
This is a very specific fear for a very niche sector of the userbase.
sudo is the only case of a silent password I've encountered in my life and it's really uncomfortable.
wao0uuno 8 hours ago [-]
How is exposing length of a password a vulnerability? My HN password is 16 characters long. Go and crack it.
gnabgib 8 hours ago [-]
Set it to 1-5 characters long, and let us know which you chose.
Dylan16807 7 hours ago [-]
Why?
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.
sethops1 8 hours ago [-]
You're missing the point. If knowing the length of a password is helpful in cracking it, then it's already too short to be effective.
gnabgib 8 hours ago [-]
The question was:
> 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.
hananova 4 hours ago [-]
Any password of a length that could feasibly be cracked by way of brute force (So up to perhaps 8?) would only save 1/N of the total time taken to crack it with N being the length if one were to know the exact length.
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.
bjourne 10 hours ago [-]
The same hackers could just listen to the key press sounds.
Tepix 24 hours ago [-]
Why not just display a single character out of a changing set of characters such as
/ - \ |
(starting with a random one from the set) after every character entered?
That way you can be certain whether or not you entered a character but and observer can‘t tell how many characters your password has.
drysart 23 hours ago [-]
There was a software package a couple decades ago, I want to say it was Lotus Notes but I'm pretty sure it wasn't actually Lotus Notes but something of that ilk, that would show a small, random number of asterisks corresponding to each character entered. So you'd hit one key and maybe two asterisks would show up on screen. And kept track of them so if you deleted a character, it'd remove two.
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.
orthoxerox 22 hours ago [-]
Yeah, I remember Lotus Notes both showing multiple filler characters per keystroke and showing different keychain pictures based on the hash of what you typed. This way you could also tell you've made a typo before submitting it.
extraduder_ire 13 hours ago [-]
If the hash changes after every character, doesn't that make it possible for someone to determine your password one character at a time if they know what each hash was?
I'm guessing that wasn't in the threat model at the time.
orthoxerox 9 hours ago [-]
Hmm. Let's say you have 64 possible characters you can use in a password and four different images. You look over someone's shoulder and see that they go "RGBYYBRYG".
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.
qnleigh 12 hours ago [-]
Yeah this reduces the time required to crack a password from
(# available characters) ^ (password length)
to
(# available characters) * (password length).
If you were patient you could crack someone's passwords by hand.
CoastalCoder 23 hours ago [-]
Back around 1996, Notes would show hieroglyphics that changed with each new password character.
ErroneousBosh 22 hours ago [-]
Yup, it was Notes, I used it at IBM. It was an unbelievably stupid idea. Every single day people were asking why their password was wrong because they were confused by the line of stars being too long.
magicalhippo 22 hours ago [-]
Notes did indeed do that, and I as I recall it was three astrix characters per password character.
jandrese 13 hours ago [-]
Unless of course your adversary can count. But if they can count they can also just count the number of keystrokes they hear, especially if you're recording it and they can spend time post processing the audio.
eapressoandcats 7 hours ago [-]
As a general rule, if you have an adversary that cares that much you’re probably doomed.
Presumably they’re capable of buying a $5 wrench to physically use against you.
g947o 22 hours ago [-]
For a new Ubuntu user, that is probably more confusing than not echoing at all.
"That way you can be certain..." absolutely not.
ErroneousBosh 22 hours ago [-]
Oh you mean like every time you type a password, it steps a spinner round? That solves the problem that IBM used to use for Notes where it showed "the wrong number of stars" which confused the hell out of users.
gzread 24 hours ago [-]
Because that's still weird and confusing to people and still serves no purpose.
creatonez 23 hours ago [-]
Sorta reminds me of the i3lock screen locker. It shows an incredibly confusing circle UI where every keystroke randomizes the position of the sector on a circle, with no explanatory text on the screen (^1). To new users, it's not clear at all that you are entering your user password or even that it's a screen locker at all, because it just looks like a cryptic puzzle.
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.
Now that you mention i3lock, if sudo showed a symbol changing with each keystroke, it could show it's working (not frozen, accepting input) without revealing the length, similarly to i3lock. I've seen ascii loading spinners from package managers by changing between slashes and hypens and such. Something of that sort would probably do the trick.
nananana9 24 hours ago [-]
Purpose:
> That way you can be certain whether or not you entered a character
gzread 24 hours ago [-]
And the shoulder surger can still count the number of times it changes so you might as well just be normal.
They can also count the number of keystrokes they heard.
Tepix 24 hours ago [-]
The echoed stars should disappear when you press enter, that way you are not revealing this information when you share a screen capture.
ErroneousBosh 22 hours ago [-]
ATM keypads are very carefully designed so that all the buttons sound exactly the same, so you can't lift a PIN by recording the sound.
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.
oneeyedpigeon 23 hours ago [-]
Surely looking at your screen seconds/minutes/hours later is the greater risk vector?
blackhaz 23 hours ago [-]
It's surprising to see an OS, dominant as a sever platform, now optimizing catering to people who are unsure whether they've pressed a button on their keyboard. What's next, replacing asterisks with a progress bar?
johnisgood 13 hours ago [-]
You are down-voted, but if we consider this to be the reason, it is indeed sad.
You can no longer filter out power users of computers based on their choice of OS alone. :D
rabf 23 hours ago [-]
Password recovery where you enter your mothers maiden name and favourite food.
jadamson 24 hours ago [-]
I don't understand your suggestion. If you're still showing one character after each character entered, what's changed?
What's the benefit of having a random character from a random set, instead of just a random character?
oneeyedpigeon 23 hours ago [-]
I think the idea is that each character overwrites the previous, so you're never showing the total length (apart from 0/1!)
jadamson 23 hours ago [-]
Ah, and the characters are supposed to be an ASCII spinner.
I think if I was new to Linux that would confuse the life out of me :)
NiloCK 23 hours ago [-]
There's no persistent reveal of password length after you're finished typing. It reduces the length-reveal leak from anyone who eventually sees the terminal log to people who are actively over-the-shoulder as you type it.
ordu 21 hours ago [-]
If you can see 1 char from set of 4 you know the number of characters modulo 4. If the minimum length of a password is 6, and probably it is no longer than 12 characters, then you can narrow the length to 1 or 2 numbers. It is marginally better than asterisks of course, of course, but it is still confusing.
NiloCK 16 hours ago [-]
The original suggestion included randomizing the first character of the set, which removes this attack.
DrawTR 23 hours ago [-]
They mean to have a static single character on the screen and have it change with every keypress. For example, you type "a" and it shows /. You type "b" and it shows "|", etc.
goodcanadian 22 hours ago [-]
Fascinating . . . reading the comments, it seems like the vast majority think this is a long overdue change. For myself, it never occurred to me that there was any issue and I'm slightly unsettled by the change (i.e. it is far from obvious to me that it's a good thing). It is not something I've thought deeply about, of course.
ahofmann 22 hours ago [-]
Because you long forgot how confusing it was, that you can't see if your keystrokes are accepted by the machine. This is a change for people, that are new to Linux/Unix
opan 18 hours ago [-]
Worse than this issue, but kind of related, sometimes TTY1 (and maybe also the other TTYs) is being spammed by log info on boot, and if you have a TTY login it isn't obvious you can just log in anyway. Had a friend using Arch+i3 with TTY login, pretty new to GNU/Linux in general, so he kinda threw up his hands like "ah dang, can't log in, it's broken". I tried to tell him to just type his credentials anyway, but he didn't get what I was saying at first. Took a bit before we got him logged in and could address the other issues. I've had similar issues on my machines. I once had kernel log verbosity cranked up by accident, copied my config from another machine where I was chasing a GPU bug. Well, the same settings on the other machine were presenting way worse, constant never-ending line-spam, before and after login. Had to get into a graphical environment half-blind to see what I was doing and then turn down the verbosity. IMO there should be an easier way around that.
pas 15 hours ago [-]
kernel cmdline arguments set in the bootloader? though I'm not sure which has precedence
fortyseven 20 hours ago [-]
Good things always happen when you cater to the lowest common denominator.
12 hours ago [-]
antisol 17 hours ago [-]
I expect there's an audience selection bias at work: Fewer greybeards and more spiky haired teens reading HN.
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.
kronks 33 minutes ago [-]
[dead]
the_real_cher 15 hours ago [-]
Just so you know. I feel the same way!
wpm 11 hours ago [-]
So, the article says that sudo hid the password by default because of shared terminals and so on.
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
sitting on a printout in a trash can? Yeah, obvious security issue.
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.
tosti 9 hours ago [-]
Not just that. There's no escape sequence to tell a terminal to draw every character input as something else and if there was, it may not have worked across all the different terminals out there.
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.
smallstepforman 1 hours ago [-]
I’m so frustrated that the default for password fields is “hidden”. The number of times I had someone observing me type a password is < 0.001% of password entries. There is a post it note on most peoples monitors with visible passwords anyway.
Reverse the logic and make a “sudo_h” script which hides the password entry for those rare times you need it.
kaveh_h 47 minutes ago [-]
If the issue is knowing that input is being registered they could’ve going with something that does not indicate length, like a rotating fixed place character that shifts at each key press, indicating input is received without showing length.
moonlion_eth 26 minutes ago [-]
just swapped out sudo with sudo-rs. only because nixos and easy heh
JoshTriplett 13 hours ago [-]
I'm glad to see this change. This was already the case for GUI password prompts, and I'm happy to see terminals following suit.
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".
croes 12 hours ago [-]
So giving others a way to know the length of your password isn’t a meaningful reduction of security?
wolttam 12 hours ago [-]
Think of it this way: there’s a button to show your actual password in the majority of applications nowadays.
`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
croes 12 hours ago [-]
Knowing the length makes is defined easier, maybe not easy but easier.
hananova 4 hours ago [-]
It saves 1/Nth of the total time taken to brute force an N character password compared to starting from length 1. So any password where this is a significant fraction is so short that the time saved isn't really relevant.
So yes, "easier", technically. But not in any meaningful way.
christophilus 12 hours ago [-]
No, not really. If you have people watching you so closely, there’s a good chance they can watch your fingers on the keyboard, too. Maybe you’re sharing your screen for a presentation, this might be slightly ill advised, but then, you should run such things in a VM or container and use silly demo passwords.
croes 12 hours ago [-]
People watching you through cameras through a window can more likely see your screen than your keyboard.
Or think of TEMPEST attacks
eapressoandcats 6 hours ago [-]
It really isn’t. The threat model is someone who can watch you type a sudo command, and has physical access to your computer to try to brute force combinations, or a way to access a backup of your hard drive or passwords file.
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.
JoshTriplett 10 hours ago [-]
Correct, it is not a meaningful reduction of security. In terms of information theory, the search-space reduction will not take make a strong password tractable. And that's leaving aside that you could already get that information via sound, or visually by looking at the keyboard. And GUIs already gave the length of the password, it was only some text-based applications that gave zero password feedback.
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.
CDSlice 12 hours ago [-]
If your password is long enough it doesn’t matter if they know it is say 16 characters and if it isn’t long enough it also doesn’t matter because they can just brute force all the potential lengths up to it. So yes it is just security theater.
croes 11 hours ago [-]
Giving away the password length helps attackers to select the easier target.
JoshTriplett 10 hours ago [-]
That's an argument for telling people the strength of their password, and warning them when setting a weak password. It's not an argument for decreasing usability in a fashion that will make people less comfortable typing long, complex passwords.
Aeolos 11 hours ago [-]
It is not, from a statistical perspective.
ryancnelson 11 hours ago [-]
“ That behaviour survived — untouched — through nearly half a century of Linux distributions” … LOL
ryancnelson 11 hours ago [-]
Linus Torvalds is 56.
emmelaich 4 hours ago [-]
This is a good change.
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.
timhh 24 hours 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 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 22 hours ago [-]
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 10 hours ago [-]
> There's no reason for it
The reason is to add a delay when bruteforcing passwords.
hananova 4 hours ago [-]
Bruteforcing is only really done with the password hashes in hand. Attacks on live systems are done with credential stuffing.
egorfine 19 hours ago [-]
> 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 24 hours ago [-]
Pretty sure the 2s delay is designed to slow down brute-forcing it.
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.
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 15 hours ago [-]
> 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 12 hours ago [-]
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 9 hours ago [-]
> You obviously can't run unix_chkpwd against a local account without root.
Wrong. At least check before you say something is obvious.
I could say the same about you, repeatedly and confidently asserting falsehoods.
caditinpiscinam 9 hours ago [-]
It surprises me how many applications don't give you the option to see your password in plain text as you enter it. The messaging around password security is that we should be making them complex and unique, but then password UIs make that as difficult to do as possible. Is visual password stealing really a bigger issue than weak passwords / password reuse?
eapressoandcats 6 hours ago [-]
Even weak passwords is almost a nonissue. No one gets even millions of tries against most passwords due to lockouts, whereas credential stuffing is a perpetual security nightmare.
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.
Havoc 21 hours ago [-]
This was actually the thing that derailed my first attempt at Linux. I was like 14 or 15 and didn’t understand that concept so couldn’t log in lol
qnleigh 12 hours ago [-]
I hope any hold-outs who aren't convinced yet will be after reading this comment!
Did you wind up sticking with Windows (or Mac) for a long time after this? How long until you tried again?
leni536 1 days ago [-]
sudo is not the only thing that prompts for password in the terminal. There is at least passwd and ssh.
I value ctrl+U a lot more for password prompts than the visual feedback, it's even used by GUI on Linux.
timhh 24 hours ago [-]
Yeah I would like to fix those too but sudo is the one I encounter most. Also the existence of sudo-rs meant there was less push-back. I seriously doubt the maintainers of openssh or passwd would accept this change.
pvillano 13 hours ago [-]
How much information is there in knowing the length of someone's password?
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
notlenin 13 hours ago [-]
For any given alphabet A, and for any positive integer n, the set of strings of length n over A is a finite set, with (number of characters in A)^n elements.
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.
hananova 4 hours ago [-]
Only if the password is infinitely long. Which it isn't. The only way knowing the length shaves off a significant amount of time during bruteforcing is if the password is already so short that the time save isn't relevant in the first place.
qayxc 10 hours ago [-]
Absolute nonsense. Apart from the fact that password length is necessarily finite due to memory and time constraints, passwords aren't stored as clear text. You will get hash collisions, because the number of unique hashes is very much finite.
Your argument therefore doesn't apply in this context.
jiehong 20 hours ago [-]
This fixes another issue with that if you make a typo in your password, you don't know how many characters you need to delete, but now you would.
opan 18 hours ago [-]
I find it's usually faster to hit ctrl-u and start over anyway.
mgbmtl 13 hours ago [-]
I have a really long passphrase in keepassxc. I often try to type it, fail 50% of the time, display the password, fix the typo. I would not use a long passphrase otherwise. (I understand there are other risks, such as having spyware that is recording my screen, but my main worry is for the safety of the file itself)
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_real_cher 16 hours ago [-]
That's been my solution too and it's never been an issue for me tbh.
prmoustache 22 hours ago [-]
How many people with a loud mechanical keyboard shut their microphone to type a password whem sharing their screen in an audio/video call?
mikkupikku 13 hours ago [-]
A good life hack I figured out is to smear your laptop camera and microphone with sticky tack, not to totally disable them but to insufferably degrade them, then after a few attempts you can be excused from the expectation of ever appearing on video calls and can disable both permanently.
opan 18 hours ago [-]
If you start by hitting backspace a few times and/or typing random characters and deleting them (to make sure the keyboard's working and sending your inputs where you think) it should obscure the length somewhat.
justsomehnguy 12 hours ago [-]
Hitting Home, End and Ins would "add" another 3 characters yet would not change the password. A full 100+ keyboard needed.
mzajc 12 hours ago [-]
A few years ago, [0] made the following point in regards to password input feedback:
> 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.
I think in OpenSSH this was mostly fixed with ObscureKeystrokeTiming which is enabled by default:
> 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.
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.
throwaway613746 9 hours ago [-]
[dead]
otterley 15 hours ago [-]
The setting to echo isn’t configurable?
timhh 15 hours ago [-]
It is. Only the default changed. Also you can press tab if someone happens to be looking over your shoulder (and your password is so obvious they can guess it from the length).
otterley 14 hours ago [-]
Sounds like the proposal to replace sudo-rs entirely throws the baby out with the bathwater, then.
linsomniac 6 hours ago [-]
Normalize asking people to turn their back if you are entering a password and they are watching your screen, for some reason.
The other side of that coin: If you see a password prompt on someone's screen, turn your back.
indubioprorubik 20 hours ago [-]
The paranoids have had a say in way to many things, way to loud, way to long.
rishabhjajoriya 10 hours ago [-]
The silent password was always a UX decision more than a security one sincee it avoided confusing new users who'd think their keyboard stopped working. removin it makes sense now that linux desktop users are generally more technical than in 1979. I still dream when will macOS people fix their login screen.
andai 11 hours ago [-]
If the UX issue is "I don't know whether the keystroke registered", isn't there a way to fix it without revealing the length? e.g. I've seen some password inputs that display multiple dots per keystroke.
Though I guess the broader context is if the attacker has "shoulder-level access" you probably have bigger things to worry about ;)
stouset 11 hours ago [-]
If the length of your password reveals enough information about the password to practically aid in discovery, your password sucks and you need to choose a new one.
accrual 11 hours ago [-]
We could flash the prompt character so user knows the keypress was received. Someone could still count the number of flashes but the number of characters wouldn't be revealed persistently. I think no feedback at all is usually best though.
SkyeCA 14 hours ago [-]
This is a good UX change, one of many UX improvements needed on CLIs.
Not showing feedback on user input is objectively confusing for inexperienced users.
dhsbdisnd 12 hours ago [-]
Seems like a decision made by and for a generation that has no regard and no understanding for UNIX.
sandreas 21 hours ago [-]
I'd think this is OK but I'm not sure if another Option to just give feedback of keyboard activity would combine the best of both worlds.
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
elaus 20 hours ago [-]
Most of those suggestions would be incredible confusing for anyone not familiar with the concept.
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.
shaky-carrousel 9 hours ago [-]
Unless either Ubuntu has 46 years or is the only distribution, then no, Ubuntu doesn't "ends 46 years of silent sudo passwords".
incompatible 3 hours ago [-]
Linux didn't even exist until the 1990s.
Edit: and the article clearly states, incorrectly, "That behaviour survived — untouched — through nearly half a century of Linux distributions."
vandyswa 17 hours ago [-]
When I wrote the login program for my VSTa microkernel, I took a page from the CDC side of the world--it echoes a _random_ (but small, non-zero) number of *'s. So you get feedback, but indeed peering over your shoulder will not disclose password length.
And yes, it remember how many it echoes so backspace works correctly.
eapressoandcats 7 hours ago [-]
One thing to note is that pretty much every other password field shows length, and the fact that sudo is so much more paranoid reminds me of this XKCD: https://xkcd.com/1200/
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.
johnisgood 14 hours ago [-]
> and further adoption of Rust-based core utilities — including uutils/coreutils
Is it usable now? Do all utilities support all of GNU's features (or most)?
I say we should allow random characters at the end of passwords.
nathell 23 hours ago [-]
The title kind of implies that silent sudo passwords have been a part of Ubuntu for the last 46 years.
tokai 13 hours ago [-]
No it doesn't. It states that sudo has had the behavior for 46 years.
throwatdem12311 12 hours ago [-]
I switched back to GNU coreutils and “regular” sudo, so I’m assuming this won’t affect me when I upgrade?
GuB-42 14 hours ago [-]
Inacceptable! This incident will be reported.
Gabrys1 13 hours ago [-]
BTW, you can also enable the PW feedback on the classic sudo. I've done that on one of my hosts
tptacek 11 hours ago [-]
Wow, sudo is a lot older than I thought it was.
sharyphil 11 hours ago [-]
I am a 30-year Windows guy.
When I work with the terminal in my Linux server I use for n8n and Outline, I think that everything is broken and that makes me hate myself.
eviks 1 days ago [-]
> sudo password is the same as their login password — one that already appears as visible placeholder dots on the graphical login screen. Hiding asterisks in the terminal while showing them at login is, in the developers’ estimation, security theatre.
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
9dev 24 hours ago [-]
This is literally never identified as an issue in any other system processing passwords. This feels like a debate by someone who once thought they had a clever idea and can’t let go despite everyone telling them it’s awful.
eviks 23 hours ago [-]
Feels like you're talking to your own strawman re. whether hiding password length makes sense, which I specifically didn't address, only pointed out that the arguments I've quoted do not support the change.
michaelmrose 24 hours ago [-]
Is there any reason to have this feature enabled for millions of desktop users vs enable by appropriately paranoid corporate IT departments?
eviks 22 hours ago [-]
The reason is to protect the innocent, of course, they're mostly clueless about security! But I don't know the level of practical benefits for this measure, superficially seems to be rather low, but then (assuming silly usability issues like "appears frozen" are fixed) what's the downside?
Elhana 23 hours ago [-]
Millions of desktop users would use empty password if they could.
mikkupikku 23 hours ago [-]
Most of them would be well enough served by that too. It used to be normal and perfectly suitable for most home users.
Neil44 22 hours ago [-]
They could give feedback about key presses without giving away the password length quite easily
data-diving 9 hours ago [-]
I’m quite impressed with the amount of ads one could cram into one single page
jeffbee 8 hours ago [-]
It is almost impossible to find the article between the adverts.
pessimizer 11 hours ago [-]
Silent sudo passwords are not a real problem. I wouldn't give up the slightest whiff of security over them. This is one of the things that I see that I have a minority position on, and it lowers my general opinion of humanity.
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.
xbar 11 hours ago [-]
This is an unnecessary downgrade in security. I hope it does not propagate to other distros.
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.
hananova 4 hours ago [-]
It's not a downgrade to security for any password length:
- 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.
blfr 1 days ago [-]
Just as you get used to something crazy after two decades, have kids, and are about to unleash it on them, it gets fixed. Will there be no boomer pleasures left for us millennials?
egorfine 19 hours ago [-]
Kids want everything done their way because the way we did it is obviously wrong and old. This has always has been the case.
nubinetwork 1 days ago [-]
Is this really the thing we're complaining about though? There's a lot more annoying things in Linux, rather than whether or not I see dots when I login...
How about all the daemons that double log or double timestamp on systemd machines?
sourcegrift 1 days ago [-]
I've been using a two character password since the last 10 years of my 23 year linux usage; I log in to console and manually start X. Guess the shame will catch up now.
mrweasel 23 hours ago [-]
Love "manually start X", because I've been considering just doing that. In some weird sense it seems easier.
adrian_b 22 hours ago [-]
You can choose the middle ground and start X in whatever file is executed by your shell at login, after checking that X is not already running and that the login has not been done remotely through SSH. Instead of using "startx" (which on a properly configured system would also start whatever desktop environment you use), you can use the start program of your desktop environment, for instance I use XFCE, whose starting program is "startxfce4".
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.
uecker 24 hours ago [-]
Funny. But I have to say the shaming of users who have different opinions or want to make different choices (the whole point of free software) is one of the saddest development in the free software world, such as the push for BSD replacements for GPL components, the entanglement of software components in general, or breaking of compatibility, etc. No matter whether you stand, that it is becoming harder to choose components in your system to your liking should give everybody pause. And if your argument involves the term "Boomer" because you prefer the new choice, you miss the point. Android should be a clear warning that we can loose freedoms again very quickly (if recent US politics is not already a warning enough).
sourcegrift 19 hours ago [-]
Sadly everyone wants convenience. Nobody hates MS because they are bad, they hate them because they are inconvenient. People are missing the fact that Google is exactly where MS was in the 90s and is most definitely as bad if not worse. I hate android sadly linux isn't looking too good rigt now on mobile.
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
uecker 17 hours ago [-]
Mobile is a problem. I had a beautifully Linux phone once, the Nokia N9. It is incredibly sad knowing how the world could look.
sourcegrift 17 hours ago [-]
* phone part
seba_dos1 16 hours ago [-]
The phone part has been working for decades now; I know cause I've been relying on it for nearly 20 years now on various devices.
uecker 12 hours ago [-]
Is there a fully usable Linux phone nowadays?
seba_dos1 12 hours ago [-]
Over the decades I have used Neo Freerunner, Nokia N900 and now Librem 5. All of them were fully usable, though I'll admit the first one required quite some patience (similarly to the PinePhone these days I'd say).
rich_sasha 23 hours ago [-]
You could reproduce your UX by switching to a 0-length password.
stevetron 16 hours ago [-]
So now there's a few additional steps when I install a new distribution to make certain that classic sudo is the one installed, rather than sudo-rs
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.
wolvoleo 14 hours ago [-]
Good!
I always thought it was annoying anyway.
Waterluvian 13 hours ago [-]
I kind of hate typing in my password all the time. Is there a way to sacrifice some security and do something like... ask for my password but automatically input it if my phone is detected via Bluetooth? (not connected, just detected).
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.
jeroenhd 10 hours ago [-]
Anything with PAM integration may work for you. I use the fingerprint reader in my laptop. Others use yubikeys.
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.
post-it 13 hours ago [-]
Mac lets you use Touch ID or your Apple Watch to authenticate sudo. I expect you could set up something custom for Linux, it seems like the type of thing AI could put together very quickly.
Gabrys1 11 hours ago [-]
you can put your password to a yubikey, then it's always a long press of a button away
the8472 13 hours ago [-]
wire up a hardware security token as a "sufficient" PAM rule. then it's just a tap.
burnt-resistor 17 hours ago [-]
Secure keyboard tty entry interaction by the terminal should manage this rather than implement it in one app. Another advantage of this method is that such affordances can be generated or silenced locally, and it's code that can be shared when used with passwd, pinentry, etc. and sudo rather than implemented N times.
jbverschoor 1 days ago [-]
Weird argument about the logging password forging the same in a gui. Because it certainly it not when logging in using a terminal locale or ssh for that matter
tsimionescu 1 days ago [-]
Either way, password lengths are exposed in virtually all scenarios except the Unix Terminal - and have caused 0 issues in practice. The default of hiding password inputs really is useless security theater, and always has been.
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.
hnlmorg 22 hours ago [-]
> and have caused 0 issues in practice
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.
SAI_Peregrinus 15 hours ago [-]
Knowing password length makes it easier to crack an insecure password.
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.
GrayHerring 14 hours ago [-]
Stop trying to fix what is not broken. If people have issues with latency or typing then the solution is not to "bypass" it.
system2 13 hours ago [-]
How many times I pressed backspace more than I typed because holding backspace probably didn't work... This is a good change IMHO. Laggy remote SSH sessions will be slightly better.
the__alchemist 14 hours ago [-]
JCBP!
the_real_cher 16 hours ago [-]
I've never once thought I wish I could see password characters when typing sudo.
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?
androiddrew 17 hours ago [-]
I don’t know why this keeps coming up. Has this been a big deal for everyone else? Like ok usability improvement, but the number of times I have read an article about this is silly.
weedhopper 13 hours ago [-]
I doubt this is about the asterisks at this point. It’s about Rust, rewriting working tools in Rust and showing that Rust is the way and the only way.
snvzz 18 hours ago [-]
If it is a new tool, why not call it something else than sudo?
The expectation with sudo is silent passwords.
post-it 13 hours ago [-]
The expectation with sudo is that it escalates the privilege of the command I want to run. They don't rename Ubuntu every time they tweak the UI.
ziml77 12 hours ago [-]
Do you also complain about GNU coreutils divergences from the original Unix utilities despite having the same names?
antisol 17 hours ago [-]
Because if you name it something different it's harder to do the "extinguish" step of "embrace, extend, extinguish".
weedhopper 13 hours ago [-]
Must’ve been hard not to name it rusdo because Rust has to come first (before any logic).
charcircuit 23 hours ago [-]
Modern password ui also gives the option to toggle the actual letters on so you can verify that you are actually typing the right thing. Hopefully that doesn't take another 46 years.
antisol 17 hours ago [-]
Oh yeah, let's echo passwords on-screen! Genius! What could possibly go wrong?
charcircuit 12 hours ago [-]
In reality not much compared to the UX win of being able to see it.
edf13 23 hours ago [-]
That site is terrible without ads blocked… it’s like a local newspaper site, you had to try and read the content in small snippets wedged between ads!
pojntfx 1 days ago [-]
It's fun, leading edge Linux distros (e.g. GNOME OS) are actually currently removing `sudo` completely in favour of `run0` from systemd, which fixes this "properly" by using Polkit & transient systemd units instead of setuid binaries like sudo. You get a UAC-style prompt, can even auth with your fingerprint just like on other modern OSes.
Instead of doing this, Ubuntu is just using a Rust rewrite of sudo. Some things really never change.
timhh 23 hours ago [-]
You make it sound like there was a discussion where they looked at these two alternatives and chose improving sudo over using run0. Actually I just submitted a patch for this and they accepted it. I don't work for Ubuntu and I didn't even know run0 existed until now (it does sound good though; I hope they switch to that).
rich_sasha 23 hours ago [-]
Why is running a command as an ephemeral systemd unit better? Just curious, I don't have an opinion one way or the other.
Without knowing more, creating a transient unit just to run a single shell command seems quite roundabout.
1una 24 hours ago [-]
It's possible to auth with your fingerprint (or even a YubiKey) in sudo. It's a functionality provided by PAM, after all.
silisili 24 hours ago [-]
Ubuntu truly are masters of going all in on being different in a worse way, only to about face soon thereafter.
You'd think by now they'd have learned, but apparently not.
necovek 23 hours ago [-]
Courage to be different is an open door to creativity.
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)
silisili 23 hours ago [-]
Ubuntu became the most used because they were the first to really dumb down the install process. No insult intended, it was my first distro as well. If you weren't around, it was rather stark. Most others had install media that just loaded a curses based install menu, asking you about partioning. Ubuntu gave you a live environment and graphical installer, which didn't ask any hard questions... way ahead of their time.
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.
necovek 22 hours ago [-]
I'd say good hw support, no nonsense live installer, and free CDs worldwide got their foot in the door. And 6 months release cycle matching GNOME + 2 months.
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).
prmoustache 22 hours ago [-]
> Ubuntu became the most used because they were the first to really dumb down the install process.
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.
silisili 11 hours ago [-]
I'd largely forgotten about Mandrake/Mandriva, did they offer a live environment with installer as a GUI application? I'd tried to install Mandrake probably closer to the year 2000 and it certainly did not, but, there's a 4 year gap there that's a blind spot for me pre-Ubuntu.
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?
necovek 22 hours ago [-]
While Ubuntu did build on Debian testing/unstable, they did invest in building the GUI on top of everything, paying salaries for a few Debian developers.
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).
dizhn 22 hours ago [-]
The free CDs they sent worldwide to whoever asked was huge too.
egorfine 19 hours ago [-]
> You'd think by now they'd have learned, but apparently not.
No. Suffering is the crucial part of virtue signaling, so bugs in slop rewrites are a feature, not a bug.
CodeCompost 24 hours ago [-]
How can you stop it asking your password every single time? I asked my LLM and it hallucinated Javascript at me.
No, they simply don't understand the history of the very thing they report on. If you look at the quoted text, they easily could have said 'Unix" terminal.
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.
devnotes77 12 hours ago [-]
[dead]
chmorgan_ 13 hours ago [-]
[dead]
gzread 1 days ago [-]
Good. It's terrible UX.
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.
zenethian 24 hours ago [-]
You got some sources or did you just make that up?
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.
9dev 24 hours ago [-]
Yet somehow, none of the other high security tools I have ever interacted with seem to do this for some reason. No auditor flags it. No security standard recommends hiding it.
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?
21 hours ago [-]
creatonez 23 hours ago [-]
And once you start adding these accessibility problems, people will respond by using weaker passwords.
hrmtst93837 10 hours ago [-]
This is security theater. Masking sudo input does nothing against keyloggers, shoulder-surfing, or anyone reading your terminal, and pretending password length is the deciding leak ignores the much larger attack surface around a compromised box. If password length is where your threat model gets scary you've already lost.
baq 22 hours ago [-]
> Because to hell with UX when it comes to security.
I don’t think you have any idea how wrong you are.
plorkyeran 16 hours ago [-]
Bad security UX that results in users bypassing security mechanisms entirely is probably the single biggest source of real-world security problems.
themafia 1 days ago [-]
> easier to turn echo on and off than to echo asterisks.
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.
mikkupikku 23 hours ago [-]
> One implies the other. You turn echo off. Then you write asterisks.
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.
themafia 21 hours ago [-]
You're correct, but, the echo and canonical mode flags are literally in the same termios structure member. One is no more complicated to change than the other. You can also easily switch to character at a time read() which makes handling backspace, erase or kill exceedingly simple.
I still doubt the claim the scheme employed by sudo was done because it "was easier."
mikkupikku 15 hours ago [-]
The first is like 3 lines of code, to get the attrs, disable the echo flag then set the attrs again. The second is.. I don't know probably about twenty lines of code to handle the primitive line editing yourself and also asterisk printing. In my view, this is enough of a difference to motivate a conclusion that the first is good enough. Also note that this decision was made back in the early 70s when login was first implemented, and it established a convention which was very easy and convienent to carry forward to su and later sudo.
uecker 24 hours ago [-]
I would be worried more about leaking the timing of the key presses.
gzread 24 hours ago [-]
Leaking the length of your password is about as bad for security as leaking the fact that you have a password, or that you use sudo.
ikari_pl 24 hours ago [-]
It narrows down the brute force domain by several orders of magnitude
23 hours ago [-]
emil-lp 24 hours ago [-]
That's obviously false. It narrows it down less than a factor the length of the password, so unless your password is several orders of magnitude, it lowers narrows by a factor of ~8.
adrian_b 21 hours ago [-]
That is obviously true, not false.
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.
hananova 3 hours ago [-]
Well yes, but now that you get feedback while you type, it's much easier to have a longer password, because typos are much easier to spot and fix.
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.
gzread 24 hours ago [-]
No, it doesn't. The set of all passwords of exactly length N is about 1% smaller than the set of all passwords up to and including length N.
adrian_b 21 hours ago [-]
The point is that you know that the password is not longer than N.
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.
gzread 21 hours ago [-]
Bruteforce search in increasing length order will find the password in within 1% of the same amount of time
themafia 21 hours ago [-]
> is about 1% smaller
Isn't it 10%?
gzread 21 hours ago [-]
If there are 9 different characters that can be in a password.
exac 23 hours ago [-]
Could we not have used braille patterns? Start on a random one and you can just replace the character with the next one so it is possible for the user to see something was entered, but password length isn't given to someone looking over the user's shoulder?
⣾, ⣽, ⣻, ⢿, ⡿, ⣟, ⣯, ⣷
jurf 22 hours ago [-]
That seems like it would be hard to see, even for the person sitting right in front of it.
imjustmsk 23 hours ago [-]
why can't they just look at the keyboard...
childintime 23 hours ago [-]
46 years of silent sudo passwords.. it just demonstrates how crazy this world is, if this is considered news. It means the code is a living fossil and people live with that fact, instead of demanding (infinite and instant) control over their systems.
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.
Retr0id 23 hours ago [-]
I'm excited about the future of mutable software, but sudo isn't exactly the kind of thing you want to be patching on-the-fly.
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.
Moreover, if someone can see the number of asterisks on the screen, what prevents them from seeing the actual keys that are being pressed?
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.
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.
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.
----
For KDE:
insert in: then reboot.----
For `sudo`:
Insert/replace `Defaults` with: ----For GNOME, you have to modify `unlockDialog.js`
And do one of the following (version-specific): or in newer version, replace `echo_char` with `null`. Reboot required.Opinionated security tools maintainers rarely get it right.
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.
Yes
How would your computer lock with capslock enabled? I.e. if capslock on that computer is set to change keyboard language?
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 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.
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
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.
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. ;)
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.
https://arxiv.org/abs/2308.01074
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.
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.
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,
Also, for anyone looking into preserving this last resort obfuscation behaviour you can do it with, On NixOS (using sudo-rs), I've got to say, if you were able to see me typing, you can probably record me doing so, bug my USB keyboard, or buy a $10 wrench. I guess for people streaming it might be worth it? I don't think it's a big enough deal to warrant the fuss around this change though, it's just an ok UX improvement that could be slightly better at retaining the sense of security.[^0]: https://github.com/google/xsecurelock#options
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).
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).
It helps 99% of the user base and the security risk seems negligible.
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.
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.
Also what demos are you doing that require sudo access to your local machine? That’s already pretty niche.
In your specific example livestreams usually have audio so the length is already public.
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.
> 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.
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.
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.
(# available characters) ^ (password length)
to
(# available characters) * (password length).
If you were patient you could crack someone's passwords by hand.
Presumably they’re capable of buying a $5 wrench to physically use against you.
"That way you can be certain..." absolutely not.
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
> 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
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 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 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
sitting on a printout in a trash can? Yeah, obvious security issue.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.
Reverse the logic and make a “sudo_h” script which hides the password entry for those rare times you need it.
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".
`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.
Or think of TEMPEST attacks
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.
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.
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.
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
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).
The reason is to add a delay when bruteforcing passwords.
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!
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.
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.
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.
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.
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.
> 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.
[0]: https://news.ycombinator.com/item?id=37309122
> 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.
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.
The other side of that coin: If you see a password prompt on someone's screen, turn your back.
Though I guess the broader context is if the attacker has "shoulder-level access" you probably have bigger things to worry about ;)
Not showing feedback on user input is objectively confusing for inexperienced users.
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.
Edit: and the article clearly states, incorrectly, "That behaviour survived — untouched — through nearly half a century of Linux distributions."
And yes, it remember how many it echoes so backspace works correctly.
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.
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
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
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.
How about all the daemons that double log or double timestamp on systemd machines?
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.
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
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.
I always thought it was annoying anyway.
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.
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.
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?
The expectation with sudo is silent passwords.
Instead of doing this, Ubuntu is just using a Rust rewrite of sudo. Some things really never change.
Without knowing more, creating a transient unit just to run a single shell command seems quite roundabout.
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.
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).
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.
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?
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).
No. Suffering is the crucial part of virtue signaling, so bugs in slop rewrites are a feature, not a bug.
What?!
2026 minus 46 is 1980. There was no Linux, at all, in 1980.
Someone is quite confused.
https://www.sudo.ws/about/history/
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.
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.
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.
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.
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."
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.
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%?
⣾, ⣽, ⣻, ⢿, ⡿, ⣟, ⣯, ⣷
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.