18 ms·

Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords

• SkyeCA 7mo 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.
• jbverschoor 7mo 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 7mo 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 7mo 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 7mo 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.
        • hnlmorg 7mo ago
          Knowing that user passwords have to be manually keyed, I don’t think the average person will have a 37 character password set ;) Typically they’re between 8 and 12 characters. Usually contain dictionary terms, with the first character capitalised and a numeric value at the end with an exclamation mark. If you know a little bit of information about the individual (which you likely will if you’re in a position to shoulder surf) then you can easily guess at personal details that individual might use (kids names, favourite movie, sports team, that kind of stuff) which also helps narrow the search field too. Now I’m not saying that this will apply for everyone. But you can see how knowing the password length combined with another piece of information suddenly increases the statistical probability of cracking some passwords. And this comes back to my earlier point about how security isn’t about absolutes. It’s about probabilities and risk. So there isn’t going to be a universal truth about whether this decision is correct for everyone or not.
          • tsimionescu 7mo ago
            You keep talking as if visible passwords is some scary never tried before thing. In reality, it's the almost universal norm, with Unixy terminal being the only place that does anything else. When you log into your UI (on Linux, Mac, and Windows), when you access your bank website, when you go to an ATM, when you log into your email account, and so many other places - all use a normal password input that echoes some character for every input. You also keep ignoring the fact that anyone who has access to see the length of your input in a shell has access to MUCH more useful information by watching/listening to you type. Bottom line is that there is no realistic security loss from this, except for the most extreme contrived scenarios. While sure, this is not the best choice for 100% of users, it's still the best choice for 99.99999% of them, so it really doesn't bear discussion.
• blfr 7mo 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?
  • nubinetwork 7mo 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?
  • egorfine 7mo 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.
• leni536 7mo 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 7mo 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.
• gzread 7mo 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.
  • themafia 7mo 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.
    • uecker 7mo ago
      I would be worried more about leaking the timing of the key presses.
    • gzread 7mo 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 7mo ago
        It narrows down the brute force domain by several orders of magnitude
        • gzread 7mo 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 7mo ago
• eviks 7mo 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
  • michaelmrose 7mo ago
    Is there any reason to have this feature enabled for millions of desktop users vs enable by appropriately paranoid corporate IT departments?
    • Elhana 7mo ago
      Millions of desktop users would use empty password if they could.
      • mikkupikku 7mo ago
        Most of them would be well enough served by that too. It used to be normal and perfectly suitable for most home users.
    • eviks 7mo 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?
  • 9dev 7mo 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.
• written-beyond 7mo 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.
  • augusto-moura 7mo 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.
  • ghighi7878 7mo 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 7mo 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 7mo ago
        I mean nopasswd option of sudo
    • 7mo ago
• pojntfx 7mo 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.
  • silisili 7mo 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 7mo 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 7mo 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.
• sourcegrift 7mo 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 7mo ago
    Love "manually start X", because I've been considering just doing that. In some weird sense it seems easier.
    • adrian_b 7mo 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 7mo 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).
    • 7mo ago
• Tepix 7mo 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.
  • g947o 7mo ago
    For a new Ubuntu user, that is probably more confusing than not echoing at all. "That way you can be certain..." absolutely not.
  • gzread 7mo ago
    Because that's still weird and confusing to people and still serves no purpose.
    • nananana9 7mo ago
      Purpose: > That way you can be certain whether or not you entered a character
      • gzread 7mo 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 7mo ago
          The echoed stars should disappear when you press enter, that way you are not revealing this information when you share a screen capture.
        • oneeyedpigeon 7mo ago
          Surely looking at your screen seconds/minutes/hours later is the greater risk vector?
        • 7mo ago
• timhh 7mo 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 anyone wants to rewrite PAM in Rust... :-D https://github.com/linux-pam/linux-pam/issues/778 https://github.com/linux-pam/linux-pam/issues/778
  • yonatan8070 7mo ago
    Pretty sure the 2s delay is designed to slow down brute-forcing it.
    • timhh 7mo ago
      Not for local password authentication. https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c#L105-L112 https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...
      • onraglanroad 7mo ago
        Yes, for local password authentication. The code you linked to isn't the code for a wrong password. It's a check to make sure you're using a TTY. That code isn't to prevent brute force. The delay there is 10 seconds. The 2 second delay is in support.c at https://github.com/pibara/pam_unix/blob/5727103caa9404f03ef04797dd581a5b7c87886b/support.c#L600 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.
• dtech 7mo 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.
  • Freak_NL 7mo 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 7mo 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 7mo 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 7mo 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. https://arxiv.org/abs/2308.01074 https://arxiv.org/abs/2308.01074
• childintime 7mo 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 7mo 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.
• charcircuit 7mo 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 7mo ago
    Oh yeah, let's echo passwords on-screen! Genius! What could possibly go wrong?
    • charcircuit 7mo ago
      In reality not much compared to the UX win of being able to see it.
• exac 7mo 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? ⣾, ⣽, ⣻, ⢿, ⡿, ⣟, ⣯, ⣷
  • imjustmsk 7mo ago
    why can't they just look at the keyboard...
  • jurf 7mo ago
    That seems like it would be hard to see, even for the person sitting right in front of it.
• Elhana 7mo ago
  Deoxodizing is rather easy for now: apt install sudo-ws apt remove coreutils-from-uutils --allow-remove-essential
  • egorfine 7mo ago
    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.
    • throwaway613746 7mo ago
      [dead]
  • otterley 7mo ago
    The setting to echo isn’t configurable?
    • timhh 7mo 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 7mo ago
        Sounds like the proposal to replace sudo-rs entirely throws the baby out with the bathwater, then.
• edf13 7mo 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!
• b112 7mo ago
  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 7mo ago
    sudo is from 1980, that's probably what they meant https://www.sudo.ws/about/history/ https://www.sudo.ws/about/history/
    • b112 7mo ago
      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.
      • andrewshadura 7mo ago
        Judging by the style of the tables and the overall sloppiness, it looks like the article was authored using Claude.
• nathell 7mo ago
  The title kind of implies that silent sudo passwords have been a part of Ubuntu for the last 46 years.
  • tokai 7mo ago
    No it doesn't. It states that sudo has had the behavior for 46 years.
• goodcanadian 7mo 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 7mo 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
    • fortyseven 7mo ago
      Good things always happen when you cater to the lowest common denominator.
    • opan 7mo 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 7mo ago
        kernel cmdline arguments set in the bootloader? though I'm not sure which has precedence
• Neil44 7mo ago
  They could give feedback about key presses without giving away the password length quite easily
• prmoustache 7mo 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?
  • opan 7mo 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 7mo ago
      Hitting Home, End and Ins would "add" another 3 characters yet would not change the password. A full 100+ keyboard needed.
    • prmoustache 7mo ago
      I was not thinking about the length but the actual keypress recognition. If you have enough recording of all kind of keypresses many keys/characters can be recognized from the waveform itself, including the backspace and delete ones. I doubt this is a super common threat but I would expect it to be already applied by spies or "Jia Tan" like employees.
  • mikkupikku 7mo 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.
• Havoc 7mo 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 7mo 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?
• sandreas 7mo 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 7mo 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.
• indubioprorubik 7mo ago
  The paranoids have had a say in way to many things, way to loud, way to long.
• jiehong 7mo 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 7mo ago
    I find it's usually faster to hit ctrl-u and start over anyway.
    • the_real_cher 7mo ago
      That's been my solution too and it's never been an issue for me tbh.
    • mgbmtl 7mo 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.
• snvzz 7mo ago
  If it is a new tool, why not call it something else than sudo? The expectation with sudo is silent passwords.
  • antisol 7mo ago
    Because if you name it something different it's harder to do the "extinguish" step of "embrace, extend, extinguish".
    • weedhopper 7mo ago
      Must’ve been hard not to name it rusdo because Rust has to come first (before any logic).
  • post-it 7mo 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 7mo ago
    Do you also complain about GNU coreutils divergences from the original Unix utilities despite having the same names?
• androiddrew 7mo 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 7mo 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.
• burnt-resistor 7mo 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.
• vandyswa 7mo 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.
• b0ringdeveloper 7mo ago
  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 7mo ago
    I would absolutely install this.
  • chuckadams 7mo ago
    Do like Lotus Notes did and have it update a row of literal hieroglyphics on every keystroke.
    • andai 7mo 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.
      • morkalork 7mo 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
      • necovek 7mo 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!
  • stavros 7mo 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.
• stevetron 7mo 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.
• the_real_cher 7mo 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?
• GrayHerring 7mo 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.
• 0xbadcafebee 7mo 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.
  • pvillano 7mo ago
    An accessibility feature helps more people if is it is on by default.
  • post-it 7mo 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 7mo 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 7mo 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).
      • 7mo ago
• johnisgood 7mo 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)?
  • Aeolos 7mo ago
    95% of the test suite is passing today, so it's pretty close: https://github.com/uutils/coreutils-tracking/blob/main/gnu-results.svg?raw=true 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 https://github.com/orgs/uutils/projects/1
• wolvoleo 7mo ago
  Good! I always thought it was annoying anyway.
• GuB-42 7mo ago
  Inacceptable! This incident will be reported.
• the__alchemist 7mo ago
  JCBP!
• Waterluvian 7mo 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.
  • the8472 7mo ago
    wire up a hardware security token as a "sufficient" PAM rule. then it's just a tap.
  • post-it 7mo 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 7mo ago
    you can put your password to a yubikey, then it's always a long press of a button away
  • jeroenhd 7mo 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.
• pvillano 7mo 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 7mo 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.
    • qayxc 7mo 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.
    • hananova 7mo 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.
• Gabrys1 7mo ago
  BTW, you can also enable the PW feedback on the classic sudo. I've done that on one of my hosts
• system2 7mo 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.
• chmorgan_ 7mo ago
  [dead]
• JoshTriplett 7mo 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 7mo ago
    So giving others a way to know the length of your password isn’t a meaningful reduction of security?
    • christophilus 7mo 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 7mo ago
        People watching you through cameras through a window can more likely see your screen than your keyboard. Or think of TEMPEST attacks
    • wolttam 7mo 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 7mo ago
• mzajc 7mo 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. [0]: https://news.ycombinator.com/item?id=37309122 https://news.ycombinator.com/item?id=37309122
  • lyu07282 7mo ago
    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.
• devnotes77 7mo ago
  [dead]
• koolba 7mo 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 7mo 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.
    • thih9 7mo 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 7mo ago
        Maybe they're saying the key rebound to serve as capslock doesn't work on the lock screen?
        • thih9 7mo ago
          If yes, perhaps there are relatively easy ways to address this. I.e. configure the custom binding to also work on lock screen. Karabiner supports this I think. Alternatively, rebind caps lock with a custom binding and not os settings (i.e. don’t rebind keys in both a custom tool and the OS). Then, if custom bindings don’t work on lock screen, you get the default, working keyboard on lock screen.
      • riknos314 7mo ago
• throwatdem12311 7mo ago
  I switched back to GNU coreutils and “regular” sudo, so I’m assuming this won’t affect me when I upgrade?
• dhsbdisnd 7mo ago
  Seems like a decision made by and for a generation that has no regard and no understanding for UNIX.
• wpm 7mo 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 7mo 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.
• pessimizer 7mo 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 7mo 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 7mo 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.
• andai 7mo 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 7mo 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 7mo 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.
• ryancnelson 7mo ago
  “ That behaviour survived — untouched — through nearly half a century of Linux distributions” … LOL
  • ryancnelson 7mo ago
    Linus Torvalds is 56.
• sharyphil 7mo 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.
• tptacek 7mo ago
  Wow, sudo is a lot older than I thought it was.
• dietr1ch 7mo 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, # /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 https://github.com/google/xsecurelock#options
  • aidenn0 7mo ago
    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 7mo 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 7mo 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.
• rishabhjajoriya 7mo 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.
• data-diving 7mo ago
  I’m quite impressed with the amount of ads one could cram into one single page
  • jeffbee 7mo ago
    It is almost impossible to find the article between the adverts.
• shaky-carrousel 7mo 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 7mo 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."
• egberts1 7mo 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 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.
  • cozzyd 7mo ago
    Can I change my password char to an emoji?
    • egberts1 7mo ago
      Only with GNOME
      • necovek 7mo ago
        The "cinfiguration" for GNOME actually modifies the source code, so if that's the bar, you can do it everywhere. :)
        • herewulf 7mo 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 7mo ago
          I mean, Gnome being in JavaScript makes it easier
          • egberts1 7mo ago
• caditinpiscinam 7mo 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 7mo 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.
• econ 7mo ago
  I say we should allow random characters at the end of passwords.
• eapressoandcats 7mo 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/ 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.
• linsomniac 7mo 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.
• caijia 7mo ago
  [flagged]
• emmelaich 7mo 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.
• smallstepforman 7mo 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 7mo 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 7mo ago
  just swapped out sudo with sudo-rs. only because nixos and easy heh
• chloecv 7mo ago
  [dead]
• enyone 7mo ago
  I feel this is a good change as it also emphasizes window/terminal focus is at correct place and user do not unintentionally type the password to another focused place (chat etc.)
• anArbitraryOne 7mo ago
  I can't believe there's an easy way to revert - that's just bigotry toward MacOS
• smakt 7mo ago
  Amazing that the peanut gallery of HN dipshits is short-stroking over a full-on LLM-slop shitsite writeup about nothing. Truly, when anything in Slashdot News (delete delete) "HaCk3R Newz" has more than about 300 comments, I know it will be a merry-go-round of imbeciles regurgitating nonsense. A moronic choir of nobodies singing the same note. This one didn't disappoint.
• hestela 7mo ago
  Related to the rust rewrite, I was real confused when I had a machine on Ubuntu 25 that had sudo-rs and I was trying to debug a five year old bash script from github and it kept throwing some strange errors. Turns out sudo-rs at least at the time was missing the flag for ask pass which was quite frustrating and rubbed me the wrong way due to the "rush for rust" and sudo-rs not being a drop in replacement yet. Also it also wasn't really documented how to go back to the old sudo which I found by just installing sudo and removing sudo-rs. I was already in the processes of dropping Ubuntu for Debian so that was long term fix for me.
• lofaszvanitt 7mo ago
  I'd like to see a counter for how many times you typed sudo :D. And the time you wasted, and the ETA when it will be eradicated.
• irenetusuq 7mo ago
  [dead]
• andrewrozumy 7mo ago
  [dead]