Ubuntu 26.04 encerra 46 anos de “senha silenciosa no sudo”

• No Ubuntu 26.04 LTS, o feedback visual com asteriscos (*) a cada caractere digitado na senha ao executar o comando sudo passa a vir ativado por padrão
• Isso foi possível com a adoção do sudo-rs, reescrito em Rust, e a Canonical o adotou como sudo padrão a partir do Ubuntu 25.10
• Alguns usuários se opuseram por risco de exposição do comprimento da senha, mas os desenvolvedores enfatizam que o risco é mínimo e destacam a consistência com a tela de login
• Para restaurar o comportamento antigo, basta adicionar Defaults !pwfeedback ao arquivo sudoers, com efeito imediato
• A mudança faz parte do trabalho de modernização do sistema no Ubuntu 26.04, junto com GNOME 50, kernel Linux 7.0 e coreutils baseados em Rust

---

História da entrada de senha no sudo

• Em 1980, Bob Coggeshall e Cliff Spencer, da SUNY Buffalo, desenvolveram o primeiro sudo
  • Na época, os terminais eram frequentemente ambientes compartilhados, e a exibição da digitação foi completamente ocultada para evitar “shoulder surfing”
  • Esse design foi mantido depois por quase 46 anos em todas as principais distribuições Linux
• O Linux Mint foi o primeiro a tentar mudar isso, ativando por padrão o feedback visual em sua própria configuração
  • Distribuições principais, como o Ubuntu, mantiveram por muito tempo o método tradicional de digitação silenciosa

sudo-rs e o processo de mudança no Ubuntu

• O sudo-rs é uma implementação que reescreve completamente em Rust o sudo tradicional baseado em C

  • A Canonical o substituiu como sudo padrão no Ubuntu 25.10, mas do ponto de vista do usuário o comportamento permaneceu igual
  • Em fevereiro de 2026, foi integrado no upstream do sudo-rs um patch que ativa pwfeedback por padrão
  • A Canonical refletiu isso nas builds de desenvolvimento do 26.04, desencadeando debate na comunidade
  • Linha do tempo principal
  • 1980: desenvolvimento do sudo original, com digitação silenciosa por padrão
  • outubro de 2025: adoção do sudo-rs no Ubuntu 25.10
  • fevereiro de 2026: integração do patch que ativa pwfeedback por padrão
  • 23 de abril de 2026: lançamento previsto do Ubuntu 26.04 LTS, com exibição de asteriscos por padrão

Os dois lados do debate de segurança

• Argumentos dos críticos

  • A exibição de asteriscos revela o comprimento da senha e enfraquece o modelo de segurança anterior
  • Houve bug reports dizendo que a mudança “quebra uma medida histórica de segurança”

• Resposta dos desenvolvedores

  • Na prática, o risco de expor o comprimento da senha é mínimo; de perto, ele também pode ser inferido pelo som das teclas ou pelo movimento das mãos
  • Para a maioria dos usuários, a senha do sudo é a mesma da senha de login, e a tela de login já mostra pontos (dots)
  • Portanto, manter apenas o terminal em silêncio seria apenas “teatro de segurança (security theatre)”
  • Resumo comparativo

Item	sudo tradicional (silencioso)	sudo-rs + pwfeedback
Feedback visual	Nenhum	Exibe asteriscos a cada entrada
Exposição do comprimento da senha	Não	Sim
Consistência com a tela de login	Inconsistente	Consistente
Experiência de novos usuários	Confusa	Permite confirmar a digitação
Sessão SSH	Silenciosa	Mantém exibição de asteriscos
Possibilidade de restaurar	—	Sim (!pwfeedback)

Como restaurar o comportamento antigo

• Abra o arquivo sudoers com o comando sudo visudo e adicione a linha abaixo

  Defaults !pwfeedback  
  

• Depois de salvar, a mudança entra em vigor imediatamente em uma nova sessão de terminal
• Não é necessário reiniciar o sistema

A modernização do Ubuntu 26.04

• A mudança faz parte da modernização geral do sistema no Ubuntu 26.04 LTS “Resolute Raccoon”
  • Inclui GNOME 50 (somente Wayland), kernel Linux 7.0 e coreutils baseados em Rust (uutils/coreutils)
  • A Canonical vem reforçando a segurança de memória e uma experiência de usuário moderna com a adoção de Rust
• A controvérsia sobre os asteriscos no sudo-rs simboliza o conflito entre a filosofia Unix tradicional e a UX moderna
  • O usuário pode voltar ao comportamento anterior a qualquer momento com uma única linha de configuração
  • O padrão foi definido priorizando “a maioria dos usuários que prefere os asteriscos, em vez de iniciantes confusos diante de uma tela vazia”
• O Ubuntu 26.04 LTS está previsto para lançamento oficial em 23 de abril de 2026 e está atualmente em desenvolvimento
  • O pacote legado sudo-ws não é afetado pela mudança em pwfeedback

[sonnet]

Se o fato de ser possível descobrir o comprimento olhando por cima do ombro é uma vulnerabilidade de segurança tão séria, então por que não é obrigatório colocar protetores anti-espiada em todos os teclados com acesso a terminais Linux? Basta olhar para o teclado ou gravar com uma câmera escondida, e pronto.

[ndrgrd]

Se dá para ver isso por cima do ombro, talvez a preocupação maior devesse ser que já dá para ver os próprios dedos digitando...
Nessa distância, daria até para gravar o som e contar quantos caracteres foram digitados.
Se a segurança é tão preocupante e importante assim, então vocês deveriam usar uma chave de segurança física.

[yukinpl]

Quando o usuário faz login pelo terminal, a senha não é exibida, e mesmo no ssh, que é acesso remoto, a senha também não fica exposta. Em nenhum caso — sudo, su, passwd, ssh ou login no terminal — a senha jamais foi mostrada. Apenas a tela de login da GUI fazia isso separadamente. Na verdade, com esta mudança, a consistência fica ainda mais prejudicada.

[GN⁺]

Comentários do Hacker News

• É possível escolher uma configuração que oculta completamente qualquer indicação visual ao digitar a senha
  No KDE, adicione ShowPasswordEcho=false em /etc/sddm.conf.d/hide-password.conf e reinicie;
  no sudo, adicione Defaults !pwfeedback em /etc/sudoers.d/password-no-visual-echo;
  no GNOME, é preciso editar unlockDialog.js e mudar para set_password_char('') ou echo_char=null, depois reiniciar

  • Fiquei curioso se também dá para trocar o caractere de exibição da senha por emoji

• Em conexões SSH com alta latência, muitas vezes eu ficava em dúvida se as teclas estavam sendo registradas ao digitar no sudo
  Como VPN e autenticação IAM estavam envolvidas, eu nem tinha certeza se a nova senha já tinha sido aplicada
  Numa situação dessas, esse recurso de feedback de senha parece realmente útil. Seria ainda melhor se a Red Hat adotasse isso

  • Lembro de ter falhado ao instalar o Mandrake Linux em 2004 porque a tela de senha não mostrava nenhuma reação
    Se a UI fosse diferente naquela época, provavelmente eu teria começado a usar Linux bem antes
  • Já aconteceu muitas vezes de eu perceber no meio que tinha digitado a senha errada e ficar apertando delete sem parar
  • Meu teclado era ruim e eu não confiava na digitação, então já digitei a senha num arquivo de texto para copiar e colar
    É péssimo em termos de segurança, mas não havia ninguém olhando por cima do ombro
  • Em servidores remotos, acho melhor não digitar a senha do sudo diretamente, e sim configurar conta sem senha e autenticação por chave pública
  • Dá para confirmar se houve entrada pelo piscar do cursor, então não fica totalmente “travado”

• A tela de login do macOS também precisa ser corrigida
  O campo de senha é estreito demais e não dá feedback mesmo ao digitar senhas longas
  Se o teclado estiver instável, o processo de login fica extremamente irritante

  • Houve uma vez em que defini o Caps Lock como tecla de troca de idioma e, com a tela bloqueada, não conseguia digitar minúsculas, então tive de reiniciar
  • Instalei a versão mais recente do macOS num Mac antigo com Open Core Legacy Patcher (OCLP), mas depois da atualização a tela de login passou a ter 20 a 30 segundos de atraso por tecla
    Numa senha de 18 caracteres, só apareciam 13, então achei que a entrada tinha travado. No fim, levei 30 minutos para conseguir entrar
  • Eu gostava do método do antigo Lotus 1-2-3, em que um símbolo diferente mudava a cada tecla digitada, como se fossem hieróglifos
    O comprimento da senha ficava exposto, mas para o usuário o feedback de digitação era claro
    Há uma discussão relacionada no Security StackExchange

• Seria ótimo ter uma **versão de brincadeira que mostrasse uma string engraçada em vez de *** **
  Por exemplo, exibir senhas falsas como “iloveyouiloveyou” ou “12345612345”

  • Também seria divertido algo no estilo do Lotus Notes, em que os hieróglifos mudam a cada tecla
  • Mas esse tipo de abordagem pode facilitar contar o comprimento da senha olhando por cima do ombro
  • Ainda assim, se desse para instalar, eu usaria na hora

• Acho que essa decisão é uma mudança realmente positiva
  No começo confunde, mas a pessoa se acostuma rápido, e na prática o impacto na segurança é pequeno

  • Ainda assim, em cenários de alto risco com telescópios, monitoramento de linha de energia e ataques de temporização, continua sendo preciso ter cuidado
  • Meu pai tinha uma senha de Linux com um único caractere, e eu não sabia disso durante um suporte remoto
    O prompt silencioso escondia esse fato, mas de qualquer forma uma senha de um caractere não serve para nada
  • Antigamente várias pessoas usavam o mesmo computador, e revelar o comprimento da senha ajudava em ataques
    Hoje isso importa menos, e quem quiser ainda pode voltar ao modo silencioso
  • Se o atacante consegue ver a tela diretamente, olhar para o teclado é mais eficiente
    No fim, isso significa mais melhoria de UX do que de segurança

• Dar feedback de digitação é bom, mas talvez uma correspondência simples de 1:1 não seja a melhor opção
  Por exemplo, o xsecurelock dá feedback movendo um ponto sobre uma linha conforme a pessoa digita
  Isso mantém a sensação de entrada sem revelar o comprimento da senha
  No sudo, é possível obter o mesmo efeito com Defaults !pwfeedback
  Na prática, se um ataque com acesso físico já é possível, então o sistema provavelmente pode ser comprometido de outras formas, então eu vejo isso só como uma melhoria de UX

  • Para quem usa senha curta, expor o comprimento pode ser mais arriscado
  • Por outro lado, mostrar o comprimento digitado também pode ser útil
    Já fiquei frustrado por não saber quantos caracteres precisava apagar ao digitar a senha errada, e esse recurso resolve esse problema

• Acho que já teria sido suficiente oferecer esse novo comportamento apenas como opção
  Se o padrão mudar, o comprimento da senha pode acabar exposto quando alguém digitar sudo durante uma transmissão

  • Mas streamers normalmente conhecem esse risco e, antes da live, já abrem um shell root ou desativam o recurso
    Além disso, também dá para estimar o comprimento pelo som do teclado
  • Mudar o padrão ajuda a maioria dos usuários, e o risco de segurança é mínimo
  • Na prática, não é um grande problema se a senha não for a mesma da conta local
    Além disso, é raro usar sudo durante uma transmissão
  • Live streaming é uma situação específica, então faz sentido manter o padrão pensando no geral
  • Se for para melhorar a acessibilidade, acho melhor ativar por padrão

• Quando alguém estiver digitando uma senha, deveria existir a cultura de virar de costas
  Da mesma forma, se você vir um prompt de senha na tela de outra pessoa, deveria desviar o olhar por conta própria

• Exibir caracteres giratórios como / - \\ | a cada tecla talvez desse feedback de entrada sem revelar o comprimento

  • Antigamente, algum software — talvez da linha Lotus Notes — mostrava uma quantidade aleatória de asteriscos a cada tecla digitada
    Ao apagar, o número diminuía segundo a mesma lógica, oferecendo feedback mas confundindo o comprimento real
  • Mesmo assim, isso ainda pode confundir o usuário e não traz ganho prático
  • Um atacante também pode contar as teclas pelo som do teclado, então a diferença não é grande
  • Para iniciantes no Ubuntu, isso pode ser ainda mais confuso
  • Na época do IBM Notes, essa “incompatibilidade no número de asteriscos” também causava confusão nos usuários

• O motivo de o sudo ocultar a senha por padrão é um legado da época de terminais compartilhados e impressoras em papel (tty)
  Antes, o que era digitado podia literalmente ficar registrado no papel, então era necessário ocultar por segurança

  • Além disso, naquela época cada terminal tinha sequências de controle diferentes para mostrar caracteres substitutos, o que dificultava a compatibilidade
    Hoje isso não costuma ser um problema, e 1% dos usuários pode voltar ao comportamento antigo via configuração

[kayws426]

Sou contra isso.

[kh0324]

Imitar o Mac e trocar algo que estava perfeitamente bem por Rust
lá vem isso de novo hoje.