Por que ainda usamos senhas, mesmo que todo mundo as odeie?
As senhas são amplamente criticadas, mas continuam sendo utilizadas. Este artigo explora as razões por trás da persistência das senhas, desde a era dos mainframes até as complexidades da autenticação moderna, e oferece alternativas e ferramentas para gerenciá-las de forma mais segura.
MundiX News·14 de abril de 2026·10 min de leitura·👁 2 views
Todos criticam as senhas, mas continuam digitando-as. Mesmo onde já existem tokens, OAuth e biometria, a familiar linha "Digite sua senha" não desapareceu. Parece que nos acostumamos com a dor, mas essa resistência tem razões bastante racionais...
Venha, vou contar a história real da era dos mainframes, a dívida técnica do Unix e a ilusão do acesso sem senha, além de analisar substituições e compartilhar ótimos utilitários de senha.
A Era dos Mainframes e o Primeiro Hack
Minha história começa com como as senhas de computador surgiram. No início dos anos sessenta, os computadores ocupavam andares inteiros, o tempo de máquina custava uma quantia colossal de dinheiro e trabalhar com um programa era mais parecido com um ciclo de produção. O código era perfurado em cartões perfurados, eles eram levados aos operadores e então esperavam horas pelo resultado. Qualquer erro retornava instantaneamente o programador ao ponto de partida, onde um novo lote de cartões e uma nova abordagem já o aguardavam.
A situação mudou em 1961, quando Fernando Corbato do MIT apresentou ao mundo o primeiro sistema operacional multiusuário CTSS. Pela primeira vez, permitiu que vários engenheiros trabalhassem simultaneamente com um mainframe através de diferentes terminais.
Fernando Corbato
No entanto, os desenvolvedores precisavam de uma maneira de ocultar os dados privados uns dos outros. Então, Corbato propôs uma simples combinação de nome de usuário e palavra secreta, porque ninguém pensava em cibersegurança global, phishing ou engenharia social. Como esperado, a primeira senha de computador quase imediatamente levou ao primeiro hack.
O doutorando Alan Schirr, que queria passar mais tempo no computador compartilhado, conseguiu imprimir o arquivo de senhas do sistema e usou credenciais "emprestadas" para fazer login sob nomes diferentes para continuar trabalhando em seu próprio projeto.
Mais tarde, quando os computadores pessoais saíram dos laboratórios para os escritórios, descobriu-se que o ponto fraco do sistema não estava na arquitetura, mas na pessoa. As pessoas anotavam senhas em pedaços de papel, contavam aos colegas e, com surpreendente facilidade, reduziam a zero o significado de toda essa proteção.
Em 2014, o próprio Corbato chamaria as senhas de "pesadelo". E é difícil imaginar um diagnóstico mais preciso para uma tecnologia que desde o início se mostrou simultaneamente necessária, vulnerável e suspeitosamente duradoura.
A Dívida Técnica do Unix e a Dor dos Administradores
No entanto, entender por que as senhas ainda não morreram é impossível sem um breve desvio para a anatomia do Unix. Os sysadmins ainda hoje convivem com decisões tomadas nos anos setenta. Por exemplo, um artefato revelador da época é /etc/passwd.
Originalmente, o kernel do sistema exigia que ele permanecesse legível para todos os usuários, porque utilitários como ls e ps precisavam mapear UIDs numéricos para logins. Se o acesso ao arquivo fosse fechado, o SO começaria a exibir números em vez do nome do proprietário do processo.
O problema era que, nas primeiras versões do Unix, os hashes de senha eram armazenados diretamente neste arquivo. Os engenheiros da época acreditavam que a criptografia era uma medida de proteção suficiente, pois os processadores fracos não conseguiam percorrer rapidamente as combinações necessárias.
Quando o poder computacional aumentou muitas vezes, os desenvolvedores tiveram que criar urgentemente um arquivo shadow /etc/shadow e esconder os hashes compilados lá. O antigo arquivo passwd permaneceu no lugar para compatibilidade com versões anteriores do software.
Outra dor está associada ao PAM - um sistema de autenticação no Linux. Foi concebido como uma configuração de login flexível através de diferentes módulos, mas acabou se tornando um emaranhado de dependências de perfis, exceções e o legado de soluções antigas.
Administradores experientes sabem o quão difícil era mudar as políticas de senha através de utilitários de console como authconfig, porque os scripts em Python reescreviam avidamente as configurações e o sistema não tolerava algumas combinações de módulos.
Agora existe uma história semelhante com o authselect. Mesmo em um servidor doméstico, abandonar uma senha geralmente requer edição manual da configuração do PAM.
Ao mesmo tempo, você pode rir o quanto quiser de combinações como Admin123, mas mesmo esse "bilhete de entrada" é mais fácil do que lidar com biometria, tokens e clientes SSO tortuosos. Especialmente à noite, quando você precisa fazer login com urgência.
A Ilusão do Acesso Sem Senha
Hoje, GRANDES empresas de tecnologia com GRANDE entusiasmo oferecem ao mundo tokens, SSO e biometria: "Finalmente, sem 123456, sem adesivos sob o teclado, sem fraqueza humana". No entanto, o acesso sem senha geralmente significa o aparecimento de outra camada sobre a senha. Por quê?
Primeiro, em qualquer empresa, serviços de nuvem, painéis internos, bancos de dados monolíticos, sistemas antigos e vários outros aplicativos funcionam em pé de igualdade, que ninguém mais quer tocar sem uma boa razão. Convencer toda essa economia a funcionar igualmente bem com tokens de hardware e SSO é quase impossível.
Sim, existem plataformas como HashiCorp Vault Enterprise que podem emitir contas SSH temporárias, certificados SPIFFE e outros sinais de "maturidade de infraestrutura". Mas com eles vêm licenças, implementação complexa e treinamento da equipe.
Em segundo lugar, há um problema mais irônico. A vulnerabilidade mais lógica dos novos conceitos sem senha está oculta nos mecanismos de acesso de backup. As chaves de hardware simplesmente quebram, os scanners de impressão digital ficam sujos, os smartphones de trabalho com aplicativos de autenticação se perdem no metrô. Absolutamente qualquer infraestrutura corporativa deve ter um canal confiável para restaurar o controle - quase sempre se torna uma senha de texto clássica.
Em terceiro lugar, um fenômeno cultural separado foi a adaptação extremamente rápida dos hackers à autenticação multifator. Os invasores estão aplicando em massa e com sucesso ataques do tipo MFA Bombing.
O acesso sem senha real requer estritamente a remoção física de linhas de código secretas de absolutamente todos os bancos de dados, o que é completamente inatingível para a grande maioria até agora.
Ferramentas de Autenticação Moderna
Se nos afastarmos da conversa eterna sobre o fato de que "as senhas estão prestes a morrer", verifica-se que elas ainda não estão indo a lugar nenhum. Os métodos modernos de autenticação resolvem principalmente não o problema do segredo, mas o problema de sua forma. O próprio princípio permanece o mesmo - o sistema deve entender que a pessoa à sua frente é quem ela diz ser.
FIDO2 e WebAuthn
Talvez esta seja a alternativa mais madura para uma senha clássica das que realmente chegaram à operação. O dispositivo cria um par de chaves - pública e privada. A privada permanece dentro do token ou armazenamento protegido, e o login é baseado na confirmação da propriedade da chave. O próprio segredo não é transmitido pela rede.
No entanto, para que FIDO2 e WebAuthn funcionem, é necessário suporte do navegador, aplicativo ou agente de terminal. Se estivermos lidando com uma API sem front-end ou um sistema interno antigo, essa autenticação só pode ser anexada sobre a arquitetura existente. Quão confiável é isso é uma questão.
OAuth 2.0 e OpenID Connect
Esses protocolos não removem senhas, mas as delegam. O usuário faz login com seu provedor de identidade e o serviço aceita um token - como um passe. Bom para a web, ruim para CLI, pior ainda para redes sem acesso externo.
Chaves SSH e corretores de autenticação
Uma solução antiga que vive melhor do que todas. Criptografia pública, verificação de assinatura e integração simples. No entanto, há um problema no gerenciamento - quem emitiu a chave, quem a revogou, quem deixou a empresa e a chave permaneceu, quem a gerou em uma máquina aleatória e depois se esqueceu dela.
Iniciativas Passkey do Google, Apple, Microsoft
Eles prometem sincronização de chaves entre dispositivos, livram você da entrada manual, mas prendem o usuário dentro do ecossistema. Bom para uso pessoal, mas inaceitável para administradores corporativos, porque você precisa de autonomia local, e não dependência da nuvem e seu tempo de atividade.
Criptografia Ed25519 e PGP
Na criptografia, o segredo não é transmitido, mas confirmado por meio de uma assinatura. A solução funciona se todos os componentes souberem como verificá-la. Mas em um mundo onde metade dos daemons corporativos foram escritos há vinte anos, implementar este esquema é mais uma dor para o administrador.
Em vez de uma conclusão
Uma percepção se impõe (espero que compreensível para todos) - as ferramentas de autenticação devem ser usadas não em vez de senhas, mas junto com elas. Portanto, como prometido, estou compartilhando uma lista de utilitários de senha adequados para uso pessoal e corporativo.
Se você quiser se proteger, eles o ajudarão:
KeePassXC
um gerenciador de senhas offline de desktop. Armazena o banco de dados localmente, suporta plug-ins de navegador, chaves de hardware e é conveniente para quem prefere controle total sobre o arquivo de senha.
Keepass2Android / KeePassDX
clientes móveis para bancos de dados compatíveis com KeePass. Permitem que você carregue um "contêiner" de senha criptografado em seu telefone e não dependa da nuvem.
Proton Pass
gerenciador de senhas da equipe Proton. Enfatiza a privacidade, criptografia "do lado do cliente" e facilidade de uso.
1Password
uma opção paga, mas muito conveniente, se você quiser "configurar e esquecer". Clientes bonitos, dicas sobre senhas fracas e vazadas, trabalho conveniente em um telefone e laptop ao mesmo tempo.
Se você precisar para atividades profissionais, preste atenção neles:
Bitwarden
gerenciador de senhas multiplataforma de código aberto, há uma nuvem e uma opção de auto-hospedagem. Pode gerar, preencher automaticamente, compartilhar registros e trabalhar em todas as principais plataformas.
HashiCorp Vault
uma das principais ferramentas para armazenar e emitir segredos. Ele tem uma API, políticas de acesso e geração dinâmica de credenciais temporárias.
Utilitário Pass (Standard Unix Password Manager)
utilitário no espírito da antiga abordagem Unix. Usa GPG e git, é facilmente automatizado, vive bem em scripts e cenários devops.
gopass
uma "extensão" avançada sobre pass em Go. Adiciona comandos convenientes, estrutura de armazenamento, suporte para trabalho em equipe e suaviza um pouco os cantos do pass clássico.
FreeIPA
uma solução abrangente para autenticação Linux e Unix. Dentro do LDAP, Kerberos, DNS, seu próprio centro de certificação e integração com o Active Directory. Além de senhas, suporta TOTP e FIDO2/passkey.
Passbolt
um gerenciador de senhas de equipe com foco no navegador e colaboração. Código aberto, servidor em casa, conveniente para distribuir acesso à equipe sem copiar segredos em mensageiros.
Então, conclusão. As senhas podem ser criticadas o quanto você quiser por phishing, fraqueza e dependência da memória humana. Tudo isso é verdade, mas ainda não há uma substituição completa para elas. É por isso que ainda usamos senhas, mesmo que todo mundo as odeie...
E meu meme favorito:
Compartilhe quais armazenamentos/serviços/utilitários você usa. Você acha que chegará um momento em que as senhas realmente não serão necessárias?
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Todos criticam as senhas, mas continuam digitando-as. Mesmo onde já existem tokens, OAuth e biometria, a familiar linha "Digite sua senha" não desapareceu. Parece que nos acostumamos com a dor, mas essa resistência tem razões bastante racionais...
Venha, vou contar a história real da era dos mainframes, a dívida técnica do Unix e a ilusão do acesso sem senha, além de analisar substituições e compartilhar ótimos utilitários de senha.
A Era dos Mainframes e o Primeiro Hack
Minha história começa com como as senhas de computador surgiram. No início dos anos sessenta, os computadores ocupavam andares inteiros, o tempo de máquina custava uma quantia colossal de dinheiro e trabalhar com um programa era mais parecido com um ciclo de produção. O código era perfurado em cartões perfurados, eles eram levados aos operadores e então esperavam horas pelo resultado. Qualquer erro retornava instantaneamente o programador ao ponto de partida, onde um novo lote de cartões e uma nova abordagem já o aguardavam.
A situação mudou em 1961, quando Fernando Corbato do MIT apresentou ao mundo o primeiro sistema operacional multiusuário CTSS. Pela primeira vez, permitiu que vários engenheiros trabalhassem simultaneamente com um mainframe através de diferentes terminais.
Fernando Corbato
No entanto, os desenvolvedores precisavam de uma maneira de ocultar os dados privados uns dos outros. Então, Corbato propôs uma simples combinação de nome de usuário e palavra secreta, porque ninguém pensava em cibersegurança global, phishing ou engenharia social. Como esperado, a primeira senha de computador quase imediatamente levou ao primeiro hack.
O doutorando Alan Schirr, que queria passar mais tempo no computador compartilhado, conseguiu imprimir o arquivo de senhas do sistema e usou credenciais "emprestadas" para fazer login sob nomes diferentes para continuar trabalhando em seu próprio projeto.
Mais tarde, quando os computadores pessoais saíram dos laboratórios para os escritórios, descobriu-se que o ponto fraco do sistema não estava na arquitetura, mas na pessoa. As pessoas anotavam senhas em pedaços de papel, contavam aos colegas e, com surpreendente facilidade, reduziam a zero o significado de toda essa proteção.
Em 2014, o próprio Corbato chamaria as senhas de "pesadelo". E é difícil imaginar um diagnóstico mais preciso para uma tecnologia que desde o início se mostrou simultaneamente necessária, vulnerável e suspeitosamente duradoura.
A Dívida Técnica do Unix e a Dor dos Administradores
No entanto, entender por que as senhas ainda não morreram é impossível sem um breve desvio para a anatomia do Unix. Os sysadmins ainda hoje convivem com decisões tomadas nos anos setenta. Por exemplo, um artefato revelador da época é /etc/passwd.
Originalmente, o kernel do sistema exigia que ele permanecesse legível para todos os usuários, porque utilitários como ls e ps precisavam mapear UIDs numéricos para logins. Se o acesso ao arquivo fosse fechado, o SO começaria a exibir números em vez do nome do proprietário do processo.
O problema era que, nas primeiras versões do Unix, os hashes de senha eram armazenados diretamente neste arquivo. Os engenheiros da época acreditavam que a criptografia era uma medida de proteção suficiente, pois os processadores fracos não conseguiam percorrer rapidamente as combinações necessárias.
Quando o poder computacional aumentou muitas vezes, os desenvolvedores tiveram que criar urgentemente um arquivo shadow /etc/shadow e esconder os hashes compilados lá. O antigo arquivo passwd permaneceu no lugar para compatibilidade com versões anteriores do software.
Outra dor está associada ao PAM - um sistema de autenticação no Linux. Foi concebido como uma configuração de login flexível através de diferentes módulos, mas acabou se tornando um emaranhado de dependências de perfis, exceções e o legado de soluções antigas.
Administradores experientes sabem o quão difícil era mudar as políticas de senha através de utilitários de console como authconfig, porque os scripts em Python reescreviam avidamente as configurações e o sistema não tolerava algumas combinações de módulos.
Agora existe uma história semelhante com o authselect. Mesmo em um servidor doméstico, abandonar uma senha geralmente requer edição manual da configuração do PAM.
Ao mesmo tempo, você pode rir o quanto quiser de combinações como Admin123, mas mesmo esse "bilhete de entrada" é mais fácil do que lidar com biometria, tokens e clientes SSO tortuosos. Especialmente à noite, quando você precisa fazer login com urgência.
A Ilusão do Acesso Sem Senha
Hoje, GRANDES empresas de tecnologia com GRANDE entusiasmo oferecem ao mundo tokens, SSO e biometria: "Finalmente, sem 123456, sem adesivos sob o teclado, sem fraqueza humana". No entanto, o acesso sem senha geralmente significa o aparecimento de outra camada sobre a senha. Por quê?
Primeiro, em qualquer empresa, serviços de nuvem, painéis internos, bancos de dados monolíticos, sistemas antigos e vários outros aplicativos funcionam em pé de igualdade, que ninguém mais quer tocar sem uma boa razão. Convencer toda essa economia a funcionar igualmente bem com tokens de hardware e SSO é quase impossível.
Sim, existem plataformas como HashiCorp Vault Enterprise que podem emitir contas SSH temporárias, certificados SPIFFE e outros sinais de "maturidade de infraestrutura". Mas com eles vêm licenças, implementação complexa e treinamento da equipe.
Em segundo lugar, há um problema mais irônico. A vulnerabilidade mais lógica dos novos conceitos sem senha está oculta nos mecanismos de acesso de backup. As chaves de hardware simplesmente quebram, os scanners de impressão digital ficam sujos, os smartphones de trabalho com aplicativos de autenticação se perdem no metrô. Absolutamente qualquer infraestrutura corporativa deve ter um canal confiável para restaurar o controle - quase sempre se torna uma senha de texto clássica.
Em terceiro lugar, um fenômeno cultural separado foi a adaptação extremamente rápida dos hackers à autenticação multifator. Os invasores estão aplicando em massa e com sucesso ataques do tipo MFA Bombing.
O acesso sem senha real requer estritamente a remoção física de linhas de código secretas de absolutamente todos os bancos de dados, o que é completamente inatingível para a grande maioria até agora.
Ferramentas de Autenticação Moderna
Se nos afastarmos da conversa eterna sobre o fato de que "as senhas estão prestes a morrer", verifica-se que elas ainda não estão indo a lugar nenhum. Os métodos modernos de autenticação resolvem principalmente não o problema do segredo, mas o problema de sua forma. O próprio princípio permanece o mesmo - o sistema deve entender que a pessoa à sua frente é quem ela diz ser.
FIDO2 e WebAuthn
Talvez esta seja a alternativa mais madura para uma senha clássica das que realmente chegaram à operação. O dispositivo cria um par de chaves - pública e privada. A privada permanece dentro do token ou armazenamento protegido, e o login é baseado na confirmação da propriedade da chave. O próprio segredo não é transmitido pela rede.
No entanto, para que FIDO2 e WebAuthn funcionem, é necessário suporte do navegador, aplicativo ou agente de terminal. Se estivermos lidando com uma API sem front-end ou um sistema interno antigo, essa autenticação só pode ser anexada sobre a arquitetura existente. Quão confiável é isso é uma questão.
OAuth 2.0 e OpenID Connect
Esses protocolos não removem senhas, mas as delegam. O usuário faz login com seu provedor de identidade e o serviço aceita um token - como um passe. Bom para a web, ruim para CLI, pior ainda para redes sem acesso externo.
Chaves SSH e corretores de autenticação
Uma solução antiga que vive melhor do que todas. Criptografia pública, verificação de assinatura e integração simples. No entanto, há um problema no gerenciamento - quem emitiu a chave, quem a revogou, quem deixou a empresa e a chave permaneceu, quem a gerou em uma máquina aleatória e depois se esqueceu dela.
Iniciativas Passkey do Google, Apple, Microsoft
Eles prometem sincronização de chaves entre dispositivos, livram você da entrada manual, mas prendem o usuário dentro do ecossistema. Bom para uso pessoal, mas inaceitável para administradores corporativos, porque você precisa de autonomia local, e não dependência da nuvem e seu tempo de atividade.
Criptografia Ed25519 e PGP
Na criptografia, o segredo não é transmitido, mas confirmado por meio de uma assinatura. A solução funciona se todos os componentes souberem como verificá-la. Mas em um mundo onde metade dos daemons corporativos foram escritos há vinte anos, implementar este esquema é mais uma dor para o administrador.
Em vez de uma conclusão
Uma percepção se impõe (espero que compreensível para todos) - as ferramentas de autenticação devem ser usadas não em vez de senhas, mas junto com elas. Portanto, como prometido, estou compartilhando uma lista de utilitários de senha adequados para uso pessoal e corporativo.
Se você quiser se proteger, eles o ajudarão:
KeePassXC
um gerenciador de senhas offline de desktop. Armazena o banco de dados localmente, suporta plug-ins de navegador, chaves de hardware e é conveniente para quem prefere controle total sobre o arquivo de senha.
Keepass2Android / KeePassDX
clientes móveis para bancos de dados compatíveis com KeePass. Permitem que você carregue um "contêiner" de senha criptografado em seu telefone e não dependa da nuvem.
Proton Pass
gerenciador de senhas da equipe Proton. Enfatiza a privacidade, criptografia "do lado do cliente" e facilidade de uso.
1Password
uma opção paga, mas muito conveniente, se você quiser "configurar e esquecer". Clientes bonitos, dicas sobre senhas fracas e vazadas, trabalho conveniente em um telefone e laptop ao mesmo tempo.
Se você precisar para atividades profissionais, preste atenção neles:
Bitwarden
gerenciador de senhas multiplataforma de código aberto, há uma nuvem e uma opção de auto-hospedagem. Pode gerar, preencher automaticamente, compartilhar registros e trabalhar em todas as principais plataformas.
HashiCorp Vault
uma das principais ferramentas para armazenar e emitir segredos. Ele tem uma API, políticas de acesso e geração dinâmica de credenciais temporárias.
Utilitário Pass (Standard Unix Password Manager)
utilitário no espírito da antiga abordagem Unix. Usa GPG e git, é facilmente automatizado, vive bem em scripts e cenários devops.
gopass
uma "extensão" avançada sobre pass em Go. Adiciona comandos convenientes, estrutura de armazenamento, suporte para trabalho em equipe e suaviza um pouco os cantos do pass clássico.
FreeIPA
uma solução abrangente para autenticação Linux e Unix. Dentro do LDAP, Kerberos, DNS, seu próprio centro de certificação e integração com o Active Directory. Além de senhas, suporta TOTP e FIDO2/passkey.
Passbolt
um gerenciador de senhas de equipe com foco no navegador e colaboração. Código aberto, servidor em casa, conveniente para distribuir acesso à equipe sem copiar segredos em mensageiros.
Então, conclusão. As senhas podem ser criticadas o quanto você quiser por phishing, fraqueza e dependência da memória humana. Tudo isso é verdade, mas ainda não há uma substituição completa para elas. É por isso que ainda usamos senhas, mesmo que todo mundo as odeie...
E meu meme favorito:
Compartilhe quais armazenamentos/serviços/utilitários você usa. Você acha que chegará um momento em que as senhas realmente não serão necessárias?
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
