Como fazer com que as senhas dos usuários sejam exibidas como texto não criptografado no Linux?

Sabemos que as senhas dos usuários são salvas /etc/passwd, mas de maneira criptografada, para que nem a raiz possa vê-las:

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

Como mostrado acima, :x:representa a senha.

Existe uma maneira (possível configuração) de salvar a senha no /etc/passwdtexto não criptografado e de forma que a raiz possa vê-las?

As outras duas respostas lhe disseram - corretamente! - que essa é uma má idéia ™ . Mas eles também disseram que é difícil , exigindo a alteração de vários programas.

Isso não é verdade. É muito fácil. Você só precisa alterar um ou dois arquivos de configuração. Eu acho importante salientar isso, porque você deve estar ciente disso ao fazer login em sistemas que não controla. Na verdade, elas não colocam uma senha em texto sem formatação /etc/passwdou /etc/shadowvão para um arquivo diferente. Observe que não os testei, pois prefiro não ter minha senha em texto sem formatação.

1. Edite /etc/pam.d/common-password(para pegar a senha alterada) ou /etc/pam.d/common-auth(para pegar o login) e adicione… pam_exec expose_authtok log=/root/passwords /bin/cat

2. Edite os dois e mude de pam_unix para pam_userdb com crypt=none. Como alternativa, você pode colocá-lo apenas na senha comum (deixando o pam_unix também) apenas para registrar as senhas quando elas forem alteradas.

3. Você pode remover a opção shadow(assim como qualquer opção de hash forte) do pam_unix para desativar o arquivo shadow e voltar às senhas tradicionais de criptografia. Não é texto simples, mas João, o Estripador, corrigirá isso para você.

Para mais detalhes, consulte o Guia de Administração do Sistema PAM .

Você também pode editar o código fonte do PAM ou escrever seu próprio módulo. Você só precisa compilar o PAM (ou seu módulo), nada mais.

Oh querida, tudo bem, vamos começar do começo ...

Sabemos que as senhas dos usuários são salvas em / etc / passwd, mas de maneira criptografada

Não eles foram armazenados em /etc/passwd, e isso foi há algum tempo atrás. Hoje, as senhas são armazenadas no chamado arquivo de sombra , na maioria das vezes /etc/shadow.

mas de maneira criptografada, para que nem a raiz possa vê-los:

Eu sei que às vezes é usado de forma intercambiável, mas hash não é criptografia . A criptografia é, por sua própria definição, reversível, o que significa que você pode converter a coisa criptografada novamente em sua forma de texto não criptografado. O hash foi projetado para não ser reversível de forma alguma (exceto força bruta). A forma original de texto não criptografado de um hash não deve ser recuperável.

As senhas no arquivo de sombra são armazenadas como hashes.

como mostrado acima: x: representa a senha

o x neste caso só é um espaço reservado para o campo de senha legado. Os xmeios que a senha pode ser encontrada no arquivo shadow.

Existe uma maneira (possível configuração) de salvar a senha no / etc / passwd em texto não criptografado e de forma que a raiz possa vê-los?

Sim, isso é realmente possível, mas não é uma boa ideia por alguns motivos. A resposta de Derobert explica uma maneira bastante simples de fazê-lo .

Mas por que não é uma boa ideia? Bem, por uma razão simples, mas muito importante: segurança. Sugiro ler estas perguntas:

• Qual é uma boa analogia para explicar por que as senhas devem ser hash para um leigo?
• Como senhas hash seguramente?
• Por que eu deveria usar hash senhas?
• Por que o hash de senha é considerado tão importante?
• Por que as funções hash são unidirecionais? Se eu conheço o algoritmo, por que não consigo calcular a entrada dele?

Mas, para resumir, assuma o seguinte: Há um servidor em uma empresa, todas as contas de usuário são protegidas por senhas e os dados nessas contas são criptografados com a mesma senha. Um cracker de fora obtém acesso ao servidor, mas não pode acessar nenhum dado importante, porque ele ainda é criptografado nas contas de usuário.

Agora assuma que as senhas seriam armazenadas em texto sem formatação. De repente, o cracker teria acesso a tudo , porque as senhas podem ser lidas. Mas se eles são armazenados como valores de hash, eles são quase inúteis para qualquer pessoa, exceto pessoas com muitos recursos para realizar um ataque de força bruta.

Primeiro, as senhas criptografadas não estão /etc/passwd, mas estão /etc/shadow. Uma das razões para isso é que /etc/passwdé legível publicamente (para que você possa, por exemplo, encontrar as informações de campo do GECOS para outro usuário) e, especialmente em esquemas de criptografia mais antigos, pode permitir ataques de força bruta contra a senha criptografada.

Para armazenar apenas as senhas em texto sem formatação, não é necessário e exigiria atualizações no programa de senhas e nas bibliotecas que lêem o arquivo /etc/shadow informações para verificar senhas válidas. E então você tem que esperar que todos os utilitários usem bibliotecas compartilhadas para acessar essas informações, em vez de serem vinculados estaticamente a algo que não entende o armazenamento de senha em texto sem formatação.

Se isso fosse uma opção na configuração de uma instalação, sempre haveria pessoas estúpidas que a ativariam de forma inadequada. E enquanto eles ainda estão trabalhando nas telas do CRT e transmitindo isso de uma maneira que pode ser facilmente captada do lado de fora do prédio, enquanto estão observando as informações.

Além disso, as pessoas tendem a usar a mesma senha ou a mesma senha em vários sistemas, de modo que não é uma boa idéia que nenhuma senha seja legível por humanos. Como um administrador de sistemas pode tentar novamente o sistema em outros sistemas, ele sabe que o usuário tem uma conta.

Deve haver coisas mais interessantes, o funcionamento do pode ser investigado em seu sistema.

O motivo básico (por que isso é uma péssima idéia) é que nenhum usuário (root, admin ou outro) deve ter acesso à senha de outro usuário.

Simplesmente porque a senha é um meio de autenticação. Se eu souber a senha de outro usuário, conheço suas credenciais (nome de usuário + senha), para que eu possa fazer login como esse usuário , representando-o (ou ela).

Qualquer ação que eu fizer ao fazer login como usuário, o outro usuário será responsável. E não é assim que a autenticação deve funcionar.

As ações podem ser desastrosas, como excluir um monte de arquivos importantes, apagar discos rígidos, apagar backups, encerrar planos de energia nuclear etc.

Ou apenas ilegal. Imagine uma instituição bancária em que eu (o administrador) tenha acesso a todas as senhas. Usando a senha do caixa, posso pedir um milhão de dólares da conta bancária do presidente para a conta bancária do limpador de janelas. Em seguida, use a senha superior do caixa para aprovar a transação. Em seguida, aprove um cheque da conta do limpador de janelas para minha própria conta bancária offshore.

Então eu vou para férias longas nas Bahamas ...

Nessa visão, o hash das senhas e o uso de arquivos de sombra separados podem ser vistos como um meio de impor essa regra (nenhum usuário deve poder se passar por outro).

E como o @ Miral comentou ^* , há a exceção de suque, ao permitir a representação (e tipos de argumentos fora do argumento acima), também está mantendo um registro de seu uso (por isso altera as regras para "apenas administradores podem se passar por outros, mas um log é mantido ").

^{* O exemplo do banco provavelmente não foi o melhor. Em qualquer ambiente em que a segurança seja crucial, geralmente são necessários mais meios de autenticação e autorização do que apenas uma senha.}