Every developer who's ever typed sudo on a Linux machine knows the feeling: you hit enter, the terminal asks for your password, and then... nothing. No cursor movement. No dots. No asterisks. Just a blinking void that makes you wonder if your keyboard just died.
Ubuntu is expected to change this in 26.04. After more than four decades of silent sudo password entry, the distribution is likely to enable pwfeedback by default, showing asterisks as you type your password. It sounds trivial. It's not. This small change touches security assumptions baked into the earliest Unix systems, and it's going to mess with the muscle memory of millions of developers and sysadmins who've never questioned that silent prompt.
Why Sudo Has Been Silent for Over 40 Years
The silent password prompt isn't a bug. It's a deliberate design decision from the era of shared physical terminals.
In the late 1970s and early 1980s, Unix systems lived in university labs and corporate offices where multiple people sat near the same terminal. If you typed your password and the screen showed eight asterisks, anyone watching now knew your password was exactly eight characters long. That's a meaningful hint for an attacker. Silent entry revealed absolutely nothing. Not the length, not the timing between keystrokes, nothing.
This design made perfect sense when your threat model was a grad student in the next chair. The original Unix password system, built by Ken Thompson and Robert Morris at Bell Labs, treated every visible signal as a potential leak. The getpass() function in early Unix simply disabled terminal echo entirely. No feedback, no information leakage.
The sudo utility itself, first written by Bob Coggeshall and Cliff Spencer at SUNY Buffalo around 1980, inherited this convention. When Todd C. Miller took over as sudo maintainer in the mid-1990s, the silent prompt was already deeply embedded in Unix culture. Nobody questioned it because it was, frankly, the correct security decision for its time.
But here's the thing nobody says about this tradition: the threat model has completely changed. Most developers in 2026 are typing sudo on a personal laptop, alone, in their own home office. The shoulder-surfing risk that justified silent entry is largely theoretical for the vast majority of users. The usability cost, though? That's very real.
The Usability Problem That's Been Hiding in Plain Sight
I've onboarded enough junior developers to know this firsthand: the silent sudo prompt is genuinely confusing for people encountering it the first time. They type their password, see nothing happen, assume something is broken, and mash keys or hit Ctrl+C. I've watched engineers with CS degrees stare at a terminal for ten seconds wondering if it froze.
This isn't a fringe complaint. The Ask Ubuntu community thread requesting asterisk feedback has been active for over a decade, accumulating hundreds of thousands of views. It's consistently one of the most popular questions about sudo configuration. People have been asking for this change for years.
The core UX problem is straightforward: every other password field in modern computing provides visual feedback. Your browser shows dots. Your phone shows dots. Your Wi-Fi login dialog shows dots. Then you drop into a terminal and suddenly you're expected to type blind. The cognitive dissonance trips up experienced developers too. I've personally mistyped passwords because I lost track of where I was in the string with zero visual anchor.
The silent prompt doesn't just confuse newcomers. It makes password entry worse for everyone by removing the basic confirmation that your keystrokes are being registered. That's not security. That's hostility.
Linux Mint recognized this years ago and ships with pwfeedback enabled by default in its sudoers file. Fewer confused users, fewer support requests about "broken" terminals, no meaningful increase in security incidents.
How the Sudo Password Asterisks Change Actually Works
The technical implementation is almost comically simple, which makes the decades-long debate around it even more interesting.
The pwfeedback flag is a sudoers option that's existed in sudo for years. When enabled, it prints an asterisk for each character typed during password entry. To enable it manually today, you'd run sudo visudo and add Defaults pwfeedback to your sudoers file. That's it. One line.
What's expected to change with Ubuntu 26.04 is the default. Instead of users needing to opt in, the distribution would ship with pwfeedback already active. The capability has been there for a long time. The shift is philosophical: Canonical is expected to decide that usability should win over the traditional security posture for their user base.
Under the hood, when sudo reads password input, it normally uses a custom implementation that disables terminal echo entirely. With pwfeedback enabled, each keystroke triggers an asterisk write to stderr. The actual password characters never touch the screen. Only the count is revealed.
For anyone who manages servers or writes automation around sudo, there's an important caveat. If you pipe input to sudo or use it in scripts with STDIN redirection, pwfeedback doesn't interfere. The flag only affects interactive terminal sessions. Your Ansible playbooks and CI/CD pipelines won't break. I've run pwfeedback on personal machines for years and never hit a scripting issue.
The Security Tradeoff Is Real, But Overblown
I'll be direct about what you give up with asterisk feedback: password length. If someone is watching your screen while you type sudo, they can count the asterisks and know your password is, say, 14 characters long.
Is that a real security concern? Technically, yes. Password length is one dimension of the search space an attacker needs to brute-force. Knowing your password is exactly 14 characters eliminates every other length from the attack surface.
But this matters far less than the silent-entry purists claim:
- If someone can see your screen, they can usually see your keyboard too. The shoulder-surfing threat model assumes the attacker can see your monitor but not your hands. That's a weirdly narrow scenario.
- Modern password security doesn't rely on length secrecy. It relies on entropy, complexity, rate limiting, and account lockouts. If knowing your password is 14 characters makes it crackable, your password was already garbage.
-
The
pwfeedbackoption had a serious vulnerability once. It was fixed. CVE-2019-18634 was a stack-based buffer overflow triggered whenpwfeedbackwas enabled, affecting sudo versions 1.7.1 through 1.8.30. Patched in early 2020. This was a bug in the implementation, not a fundamental flaw in the concept. Current versions of sudo handlepwfeedbacksafely.
Having built and maintained systems that handle authentication at scale, I think the security community's resistance to this change is mostly tradition masquerading as threat analysis. The actual risk of password length exposure in a modern context is negligible compared to the usability gains. If you're running a multi-user server in a sensitive environment, disable it. But defaults should serve the majority.
What This Means for Ubuntu 26.04 and Beyond
Full disclosure: as of this writing, Canonical hasn't formally announced that pwfeedback will be the default in Ubuntu 26.04. The change is expected based on upstream sudo project direction, community demand, and the precedent set by Ubuntu-based distributions like Linux Mint that already ship with it enabled. Ubuntu 26.04, expected in April 2026, would be the natural vehicle for this kind of default change in an LTS release.
If and when this lands, the immediate impact on most developers will be subtle. You'll type sudo apt update, enter your password, and see ************* instead of nothing. Your workflow doesn't change. Your scripts don't break. You just get a small quality-of-life improvement that brings the terminal in line with every other password field you interact with.
What I find more interesting is what this says about Linux's evolving relationship with its users. For decades, Linux defaults prioritized the concerns of system administrators managing multi-user servers. That made sense when Linux was primarily a server OS. But Ubuntu has over 40 million desktop users, and the typical Ubuntu user in 2026 is more likely a developer on a personal laptop than a sysadmin in a data center.
This fits a broader pattern I've noticed across developer tooling. The realization that good server management UX matters, even for experienced engineers. Defaults should reflect how people actually use tools, not how they were used in 1980.
Should You Enable It Now?
You don't have to wait for Ubuntu 26.04. If this article convinced you that asterisk feedback is the right call, you can enable it today on any Linux distribution in about ten seconds:
- Run
sudo visudo - Add the line
Defaults pwfeedback - Save and exit
That's it. If you later decide you hate it, remove the line. If you're managing a fleet of machines, push this via configuration management. If you're running a hardened production server where you genuinely worry about shoulder surfing, leave it off.
The security implications here are also worth thinking about in the context of how authentication is evolving broadly. Passwords themselves are increasingly a legacy mechanism. There's something almost quaint about optimizing the visual feedback of a password prompt in 2026 when passkeys and biometrics are eating the authentication world. But sudo isn't going anywhere soon, and making it less hostile to use is a straightforward win.
Here's my prediction: within two years of Ubuntu enabling asterisk feedback by default, Fedora and Debian will follow. The silent prompt will become an opt-in hardening measure rather than the default. And a decade from now, new developers will be baffled that terminals ever swallowed keystrokes without acknowledgment. They'll be right to find it weird. It was always a compromise, not a principle. The compromise just stopped making sense.
Originally published on kunalganglani.com
Top comments (0)