[HN Gopher] Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords
___________________________________________________________________
Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords
Author : akersten
Score : 290 points
Date : 2026-03-21 05:06 UTC (17 hours ago)
(HTM) web link (pbxscience.com)
(TXT) w3m dump (pbxscience.com)
| jbverschoor wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 540b5417b5ecb522715fd4bb30f41291203890
| 0bd4ba949ea6130c8cb3c16012. 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.
| blfr wrote:
| 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?
| nubinetwork wrote:
| 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?
| egorfine wrote:
| Kids want everything done their way because the way we did it
| is obviously wrong and old. This has always has been the case.
| leni536 wrote:
| 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 wrote:
| 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.
| gzread wrote:
| 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.
| themafia wrote:
| > 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.
| uecker wrote:
| I would be worried more about leaking the timing of the key
| presses.
| gzread wrote:
| 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 wrote:
| It narrows down the brute force domain by several orders of
| magnitude
| gzread wrote:
| 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 wrote:
| 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 wrote:
| Bruteforce search in increasing length order will find
| the password in within 1% of the same amount of time
| themafia wrote:
| > is about 1% smaller
|
| Isn't it 10%?
| gzread wrote:
| If there are 9 different characters that can be in a
| password.
| emil-lp wrote:
| 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 wrote:
| 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.
| mikkupikku wrote:
| > _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 wrote:
| 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 wrote:
| 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.
| zenethian wrote:
| 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 wrote:
| 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?
| creatonez wrote:
| And once you start adding these accessibility problems,
| people will respond by using weaker passwords.
| baq wrote:
| > Because to hell with UX when it comes to security.
|
| I don't think you have any idea how wrong you are.
| plorkyeran wrote:
| Bad security UX that results in users bypassing security
| mechanisms entirely is probably the single biggest source of
| real-world security problems.
| hrmtst93837 wrote:
| 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.
| eviks wrote:
| > 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
| michaelmrose wrote:
| Is there any reason to have this feature enabled for millions
| of desktop users vs enable by appropriately paranoid corporate
| IT departments?
| Elhana wrote:
| Millions of desktop users would use empty password if they
| could.
| mikkupikku wrote:
| Most of them would be well enough served by that too. It
| used to be normal and perfectly suitable for most home
| users.
| eviks wrote:
| 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?
| 9dev wrote:
| 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 wrote:
| 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.
| written-beyond wrote:
| 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.
| augusto-moura wrote:
| 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.
| ghighi7878 wrote:
| 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 wrote:
| 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 wrote:
| I mean nopasswd option of sudo
| wolvoleo wrote:
| 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 wrote:
| I did mean nopasswd option of sudo.
| Wowfunhappy wrote:
| 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!
| znpy wrote:
| 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 wrote:
| 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 wrote:
| 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.
| johnisgood wrote:
| You can tell if you input something or not, based on the
| blinking cursor, in which case it is not "frozen".
| semanticc wrote:
| Unless you disable cursor blinking because you find it
| annoying (like I do).
| setopt wrote:
| Yeah, disabling cursor blinking is the first configuration
| I do in any terminal.
| written-beyond wrote:
| 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.
| mbesto wrote:
| 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 wrote:
| Just type Control-U once.
| eptcyka wrote:
| 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_ wrote:
| > 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 wrote:
| 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.
| malfist wrote:
| What happens when you press home or end?
| fer wrote:
| > e.g. shell motions between macOS and reasonable OSes.
|
| I forgot about this since I started NixOS/home-manager
| everywhere.
| hilliardfarmer wrote:
| 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 wrote:
| 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 wrote:
| Start your password with a forward slash :)
| lxgr wrote:
| The trick is to use a plausible Slack message as your sudo
| password :)
| ornornor wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pojntfx wrote:
| 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.
| silisili wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dizhn wrote:
| The free CDs they sent worldwide to whoever asked was
| huge too.
| prmoustache wrote:
| > 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.
| necovek wrote:
| 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).
| silisili wrote:
| 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 wrote:
| 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).
| egorfine wrote:
| > 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.
| gzread wrote:
| Is "GNOME OS" really a leading distro?
| LeoPanthera wrote:
| I think they mean "leading edge".
| mikkupikku wrote:
| Losing edge.
| 1una wrote:
| It's possible to auth with your fingerprint (or even a YubiKey)
| in sudo. It's a functionality provided by PAM, after all.
| CodeCompost wrote:
| How can you stop it asking your password every single time? I
| asked my LLM and it hallucinated Javascript at me.
| bblb wrote:
| echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee
| "/etc/sudoers.d/$USER"; sudo chmod 0600
| "/etc/sudoers.d/$USER" sudo mkdir -p
| /etc/polkit-1/rules.d echo
| 'polkit.addRule(function(action, subject) { if
| (subject.isInGroup("sudo") || subject.isInGroup("wheel")) {
| return polkit.Result.YES; }});' | sudo tee
| /etc/polkit-1/rules.d/00-nopasswd.rules
| timhh wrote:
| 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).
| Elhana wrote:
| Gnome is known for shitty UX, breaking stuff every release and
| refusing to fix stuff since Gnome3.
| rich_sasha wrote:
| 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.
| sourcegrift wrote:
| 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.
| uecker wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| * phone part
| seba_dos1 wrote:
| 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 wrote:
| Is there a fully usable Linux phone nowadays?
| seba_dos1 wrote:
| 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 wrote:
| You could reproduce your UX by switching to a 0-length
| password.
| mrweasel wrote:
| Love "manually start X", because I've been considering just
| doing that. In some weird sense it seems easier.
| adrian_b wrote:
| 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.
| Tepix wrote:
| 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.
| gzread wrote:
| Because that's still weird and confusing to people and still
| serves no purpose.
| nananana9 wrote:
| Purpose:
|
| > That way you can be certain whether or not you entered a
| character
| gzread wrote:
| 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 wrote:
| The echoed stars should disappear when you press enter,
| that way you are not revealing this information when you
| share a screen capture.
| oneeyedpigeon wrote:
| Surely looking at your screen seconds/minutes/hours later
| is the greater risk vector?
| ErroneousBosh wrote:
| 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.
| blackhaz wrote:
| 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?
| rabf wrote:
| Password recovery where you enter your mothers maiden
| name and favourite food.
| johnisgood wrote:
| 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
| creatonez wrote:
| 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.
|
| ^1: Example of it in use:
| https://www.youtube.com/watch?v=FvT44BSp3Uc
| opan wrote:
| 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.
| jadamson wrote:
| 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 wrote:
| I think the idea is that each character overwrites the
| previous, so you're never showing the total length (apart
| from 0/1!)
| jadamson wrote:
| 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 :)
| DrawTR wrote:
| 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.
| NiloCK wrote:
| 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 wrote:
| 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 wrote:
| The original suggestion included randomizing the first
| character of the set, which removes this attack.
| drysart wrote:
| 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.
| CoastalCoder wrote:
| Back around 1996, Notes would show hieroglyphics that changed
| with each new password character.
| orthoxerox wrote:
| 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 wrote:
| 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.
| qnleigh wrote:
| 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.
| orthoxerox wrote:
| 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.
| ErroneousBosh wrote:
| 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 wrote:
| Notes did indeed do that, and I as I recall it was three
| astrix characters per password character.
| ErroneousBosh wrote:
| 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.
| g947o wrote:
| For a new Ubuntu user, that is probably more confusing than not
| echoing at all.
|
| "That way you can be certain..." absolutely not.
| jandrese wrote:
| 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.
| timhh wrote:
| I did this!
|
| I didn't actually know that Mint had enabled this by default.
| That would have been a useful counterpoint to the naysayers.
|
| If you want the original behaviour you don't actually need to
| change the configuration - they added a patch afterwards so you
| can press tab and it will hide the password just for that time.
|
| > The catalyst for Ubuntu's change is sudo-rs
|
| Actually it was me getting sufficiently pissed off at the 2
| second delay for invalid passwords in sudo (actually PAM's
| fault). There's no reason for it (if you think there is look up
| unix_chkpwd). I tried to fix it but the PAM people have this
| strange idea that people _like_ the delay. So I gave up on that
| and thought I may as well try fixing this other UX facepalm too.
| I doubt it would have happened with the original sudo (and they
| said as much) so it did require sudo-rs to exist.
|
| I think this is one of the benefits of rewriting coreutils and so
| on in Rust - people are way more open to fixing long-standing
| issues. You don't get the whole "why are you overturning 46 years
| of tradition??" nonsense.
|
| If anyone wants to rewrite PAM in Rust... :-D
|
| https://github.com/linux-pam/linux-pam/issues/778
| yonatan8070 wrote:
| Pretty sure the 2s delay is designed to slow down brute-forcing
| it.
| timhh wrote:
| Not for local password authentication.
|
| https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c.
| ..
| onraglanroad wrote:
| Yes, for local password authentication.
|
| The code you linked to isn't the code for a wrong password.
| It's a check to make sure you're using a TTY. That code
| isn't to prevent brute force. The delay there is 10
| seconds.
|
| The 2 second delay is in support.c at https://github.com/pi
| bara/pam_unix/blob/5727103caa9404f03ef0...
|
| It only runs if "nodelay" is not set. But you might have
| another pam module setting its own delay. I have
| pam_faildelay.so set in /etc/pam.d/login
|
| Change both the config files and you can remove the delay
| if you want.
| timhh wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| 9dev wrote:
| > If anyone wants to rewrite PAM in Rust... :-D
|
| If you do, offer support for writing modules in a scripting
| language like Lua or Python. PAM could make it a lot easier to
| just add OAuth with your company IdP, for example...
| tetha wrote:
| Ah, but then you choose the wrong language or language
| runtime and distros ship old versions for 10+ years :)
|
| (compare: polkit. Both sides have their point, but I've been
| annoyed by this standoff a few times).
| egorfine wrote:
| > You don't get the whole "why are you overturning 46 years of
| tradition??" nonsense
|
| Respectfully, we are the opposing sides of the barricades here.
| I was removing sudo-rs, uutils and some of the systemd-*
| packages from fresh Ubuntu installations until the amount of
| virtue signaling got really tiresome.
|
| Currently almost no Ubuntu left in my production. Hopefully
| Debian will not package those.
|
| PS: Rust is awesome!
| 1718627440 wrote:
| > There's no reason for it
|
| The reason is to add a delay when bruteforcing passwords.
| dtech wrote:
| 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.
| Freak_NL wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
|
| https://arxiv.org/abs/2308.01074
| 3eb7988a1663 wrote:
| 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 wrote:
| "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 wrote:
| 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.
| ahofmann wrote:
| 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.
| zx8080 wrote:
| > 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 wrote:
| If you are brute forcing passwords, knowing the length only
| reduces the number of passwords to try by like 1 hundredth.
| egeres wrote:
| It also give you the possibility of filtering out which
| ones are worth cracking and which ones not
| elcritch wrote:
| 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 wrote:
| 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.
| elcritch wrote:
| 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. ;)
| Obscurity4340 wrote:
| Its funny how a single japanese symbol would be harder to
| crack than the anglicized name for it
| LoganDark wrote:
| Do we know if the asterisks count Unicode code points
| rather than bytes?
| Izkata wrote:
| Doesn't really matter, the IME shows the input until you
| confirm which kanji you want.
| LoganDark wrote:
| 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.
| dhosek wrote:
| I've occasionally contemplated using some non-ASCII
| character like * or s in a password, but have backed off
| for fear of needing access from a device that doesn't
| support input of those characters.
| brnt wrote:
| 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.
| airstrike wrote:
| If it breaks the workflow of one person but makes it better
| for many more, it's likely a worthwhile tradeoff.
| wartywhoa23 wrote:
| How much would unknown password length protect against
| bruteforcing a 1 character password?
| nextlevelwizard wrote:
| This has always been an option and your dad can just flip the
| default back to not show it
| MattPalmer1086 wrote:
| 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 wrote:
| On the other hand streaming is way, way more common nowadays.
| childintime wrote:
| 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 wrote:
| 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.
| charcircuit wrote:
| 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 wrote:
| Oh yeah, let's echo passwords on-screen! Genius! What could
| possibly go wrong?
| charcircuit wrote:
| In reality not much compared to the UX win of being able to
| see it.
| exac wrote:
| 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?
|
| [d2345678], [d1345678], [d1245678], [d1234568], [d1234567],
| [d1234578], [d1234678], [d1235678]
| imjustmsk wrote:
| why can't they just look at the keyboard...
| jurf wrote:
| That seems like it would be hard to see, even for the person
| sitting right in front of it.
| Elhana wrote:
| Deoxodizing is rather easy for now:
|
| apt install sudo-ws
|
| apt remove coreutils-from-uutils --allow-remove-essential
| egorfine wrote:
| Yes, thankfully.
|
| 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.
| otterley wrote:
| The setting to echo isn't configurable?
| timhh wrote:
| 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 wrote:
| Sounds like the proposal to replace sudo-rs entirely throws
| the baby out with the bathwater, then.
| edf13 wrote:
| 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!
| b112 wrote:
| _For more than four decades, typing a password after a sudo
| prompt in a Linux terminal_
|
| What?!
|
| 2026 minus 46 is 1980. There was no Linux, at all, in 1980.
|
| Someone is quite confused.
| throawayonthe wrote:
| sudo is from 1980, that's probably what they meant
|
| https://www.sudo.ws/about/history/
| b112 wrote:
| 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.
| nathell wrote:
| The title kind of implies that silent sudo passwords have been a
| part of Ubuntu for the last 46 years.
| tokai wrote:
| No it doesn't. It states that sudo has had the behavior for 46
| years.
| goodcanadian wrote:
| 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 wrote:
| 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
| fortyseven wrote:
| Good things always happen when you cater to the lowest common
| denominator.
| opan wrote:
| 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 wrote:
| kernel cmdline arguments set in the bootloader? though I'm
| not sure which has precedence
| antisol wrote:
| 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.
| the_real_cher wrote:
| Just so you know. I feel the same way!
| Neil44 wrote:
| They could give feedback about key presses without giving away
| the password length quite easily
| prmoustache wrote:
| How many people with a loud mechanical keyboard shut their
| microphone to type a password whem sharing their screen in an
| audio/video call?
| opan wrote:
| 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 wrote:
| Hitting Home, End and Ins would "add" another 3 characters
| yet would not change the password. A full 100+ keyboard
| needed.
| mikkupikku wrote:
| 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.
| Havoc wrote:
| 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 wrote:
| 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?
| sandreas wrote:
| 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 wrote:
| 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.
| indubioprorubik wrote:
| The paranoids have had a say in way to many things, way to loud,
| way to long.
| jiehong wrote:
| 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 wrote:
| I find it's usually faster to hit ctrl-u and start over anyway.
| the_real_cher wrote:
| That's been my solution too and it's never been an issue for
| me tbh.
| mgbmtl wrote:
| 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.
| snvzz wrote:
| If it is a new tool, why not call it something else than sudo?
|
| The expectation with sudo is silent passwords.
| antisol wrote:
| Because if you name it something different it's harder to do
| the "extinguish" step of "embrace, extend, extinguish".
| weedhopper wrote:
| Must've been hard not to name it _rusdo_ because Rust has to
| come first (before any logic).
| post-it wrote:
| 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 wrote:
| Do you also complain about GNU coreutils divergences from the
| original Unix utilities despite having the same names?
| androiddrew wrote:
| 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 wrote:
| 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.
| burnt-resistor wrote:
| 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.
| vandyswa wrote:
| 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.
| b0ringdeveloper wrote:
| 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.
| the_real_cher wrote:
| I would absolutely install this.
| chuckadams wrote:
| Do like Lotus Notes did and have it update a row of literal
| hieroglyphics on every keystroke.
| andai wrote:
| 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.
| morkalork wrote:
| 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 wrote:
| 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.
| stevetron wrote:
| 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.
| the_real_cher wrote:
| 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?
| GrayHerring wrote:
| Stop trying to fix what is not broken. If people have issues with
| latency or typing then the solution is not to "bypass" it.
| 0xbadcafebee wrote:
| 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.
| pvillano wrote:
| An accessibility feature helps more people if is it is on by
| default.
| post-it wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| jandrese wrote:
| 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.
| boca_honey wrote:
| 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.
| roger_ wrote:
| 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 wrote:
| Rethinking would imply there was thinking going on. This
| decision was made on vibes alone.
| zarzavat wrote:
| 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 wrote:
| Yes, this mattered when 6 character passwords were common.
| zahlman wrote:
| There was already an option for a very long time, and in fact
| Mint had already changed the default since a long time ago (see
| e.g. https://forums.linuxmint.com/viewtopic.php?p=1572457).
|
| 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.
| bjourne wrote:
| The same hackers could just listen to the key press sounds.
| wao0uuno wrote:
| How is exposing length of a password a vulnerability? My HN
| password is 16 characters long. Go and crack it.
| gnabgib wrote:
| Set it to 1-5 characters long, and let us know which you
| chose.
| johnisgood wrote:
| > 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)?
| Aeolos wrote:
| 95% of the test suite is passing today, so it's pretty close:
| https://github.com/uutils/coreutils-tracking/blob/main/gnu-r...
|
| There is a list of open items here, it's looking pretty good
| tbh: https://github.com/orgs/uutils/projects/1
| wolvoleo wrote:
| Good!
|
| I always thought it was annoying anyway.
| GuB-42 wrote:
| Inacceptable! This incident will be reported.
| the__alchemist wrote:
| JCBP!
| SkyeCA wrote:
| 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.
| Waterluvian wrote:
| 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.
| the8472 wrote:
| wire up a hardware security token as a "sufficient" PAM rule.
| then it's just a tap.
| post-it wrote:
| 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 wrote:
| you can put your password to a yubikey, then it's always a long
| press of a button away
| jeroenhd wrote:
| 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.
| pvillano wrote:
| 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 wrote:
| 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.
| qayxc wrote:
| 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.
| Gabrys1 wrote:
| BTW, you can also enable the PW feedback on the classic sudo.
| I've done that on one of my hosts
| system2 wrote:
| 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.
| JoshTriplett wrote:
| 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 wrote:
| So giving others a way to know the length of your password
| isn't a meaningful reduction of security?
| christophilus wrote:
| 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 wrote:
| People watching you through cameras through a window can
| more likely see your screen than your keyboard.
|
| Or think of TEMPEST attacks
| wolttam wrote:
| 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 wrote:
| Knowing the length makes is defined easier, maybe not easy
| but easier.
| CDSlice wrote:
| 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 wrote:
| Giving away the password length helps attackers to select
| the easier target.
| JoshTriplett wrote:
| 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 wrote:
| It is not, from a statistical perspective.
| JoshTriplett wrote:
| 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.
| mzajc wrote:
| 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.
|
| [0]: https://news.ycombinator.com/item?id=37309122
| koolba wrote:
| 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 wrote:
| 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.
| thih9 wrote:
| > 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 wrote:
| Maybe they're saying the key rebound to serve as capslock
| doesn't work on the lock screen?
| echelon wrote:
| 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.)
|
| 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.
| 5-0 wrote:
| Perhaps you'd enjoy something like the xsecurelock prompts?
| https://github.com/google/xsecurelock
| bxparks wrote:
| 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.
| throwatdem12311 wrote:
| I switched back to GNU coreutils and "regular" sudo, so I'm
| assuming this won't affect me when I upgrade?
| dhsbdisnd wrote:
| Seems like a decision made by and for a generation that has no
| regard and no understanding for UNIX.
| wpm wrote:
| 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 wrote:
| 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.
| pessimizer wrote:
| 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 wrote:
| 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.
| andai wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ryancnelson wrote:
| " That behaviour survived -- untouched -- through nearly half a
| century of Linux distributions" ... LOL
| ryancnelson wrote:
| Linus Torvalds is 56.
| sharyphil wrote:
| 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.
| tptacek wrote:
| Wow, sudo is a lot older than I thought it was.
| dietr1ch wrote:
| 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, #
| /etc/sudoers Defaults !pwfeedback
|
| On NixOS (using sudo-rs), security.sudo-
| rs.extraConfig = '' # NixOS extraConfig #
| =========== Defaults !pwfeedback '';
|
| 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
| aidenn0 wrote:
| 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 wrote:
| 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.
| moffkalast wrote:
| 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 wrote:
| 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).
| rishabhjajoriya wrote:
| 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.
| data-diving wrote:
| I'm quite impressed with the amount of ads one could cram into
| one single page
| shaky-carrousel wrote:
| Unless either Ubuntu has 46 years or is the only distribution,
| then no, Ubuntu doesn't "ends 46 years of silent sudo passwords".
| egberts1 wrote:
| 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
|
| And do one of the following (version-specific):
| this._passwordEntry.clutter_text.set_password_char('');
|
| or in newer version, replace `echo_char` with `null`. Reboot
| required.
| caditinpiscinam wrote:
| 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?
___________________________________________________________________
(page generated 2026-03-21 23:00 UTC)