Como tornar as senhas de usuários mostradas como um texto claro no Linux?

Question

Sabemos que as senhas dos usuários são salvas em /etc/passwd , mas de forma criptografada, por isso mesmo a raiz não consegue 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 (configuração possível) de salvar a senha no /etc/passwd no texto não criptografado e de forma que a raiz possa vê-los?

    

Answer 1

As outras duas respostas lhe disseram - corretamente! - que essa é uma Idéia Ruim ™ . Mas eles também disseram que é muito difícil fazer isso, 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 sinto que é importante apontar isso, porque você deve estar ciente disso ao fazer login em sistemas que você não controla. Eles não colocarão uma senha de texto simples em /etc/passwd ou /etc/shadow , ela entrará em um arquivo diferente. Note que eu não testei estes, pois prefiro não ter minha senha em texto simples.

1. Edite /etc/pam.d/common-password (para pegar a senha alterada) ou /etc/pam.d/common-auth (para pegar no 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 . Alternativamente, você poderia colocá-lo apenas em uma senha comum (deixando pam_unix também) para apenas gravar senhas quando elas são alteradas.

3. Você pode remover a opção shadow (assim como qualquer opção de hash strong) do pam_unix para desabilitar o arquivo de sombra e voltar para as senhas de criptografia tradicionais. Não texto simples, mas John the Ripper vai consertar isso para você.

Para mais detalhes, verifique 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ó precisaria compilar o PAM (ou seu módulo), nada mais.

    

Answer 2

Oh querida, ok, vamos começar bem no começo ...

We know that users' passwords are saved in /etc/passwd, but in an encrypted way

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

but in an encrypted way, so even the root can't see them:

Eu sei que às vezes é usado de forma intercambiável, mas hashing não é criptografia . A criptografia é, por sua própria definição, reversível, o que significa que você pode traduzir a coisa criptografada de volta para seu formato de texto não criptografado. Hashing é projetado para ser não reversível de qualquer forma (exceto força bruta). A forma original de texto puro de algo que é hash não deve ser recuperável.

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

as shown above :x: represent the password

O x neste caso é apenas um marcador para o campo de senha herdada. O x significa que a senha pode ser encontrada no arquivo de sombra.

Is there a way (possible configuration) to save the password in the /etc/passwd in clear text and such that the root can see them?

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 um motivo simples, mas muito importante: segurança. Eu sugiro ler estas perguntas:

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

Mas, para resumir, suponha o seguinte: Existe um servidor em uma empresa, todas as contas de usuário são protegidas por suas senhas e os dados nessas contas de usuário são criptografados com a mesma senha. Um cracker do lado de fora ganha acesso ao servidor, mas eles não podem acessar nenhum dado importante porque ele ainda está criptografado nas contas de usuário.

Agora, suponha que as senhas sejam armazenadas em texto simples. O cracker de repente teria acesso a tudo , porque as senhas podem ser lidas. Mas se eles são armazenados como valores com hash, eles são quase inúteis para qualquer um, exceto pessoas com muitos recursos para fazer um ataque de força bruta.

    

Answer 3

Em primeiro lugar, as senhas criptografadas não estão em /etc/passwd , mas estão em /etc/shadow . Uma das razões para isso é que /etc/passwd é publicamente legível (portanto, você pode encontrar as informações de campo GECOS para outro usuário) e, especialmente com esquemas de criptografia mais antigos, 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 leiam as informações de /etc/shadow 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 estarem estaticamente ligados a algo que não entende o armazenamento de senhas em texto puro.

Se isso fosse uma opção na configuração de uma configuração, sempre haveria pessoas estúpidas que a desativariam de maneira inadequada. E enquanto eles ainda estão trabalhando nas telas CRT e transmitem isso de uma maneira que pode ser facilmente captada de fora do prédio, enquanto eles estão olhando para a informação.

Além disso, as pessoas tendem a usar a mesma senha ou uma senha semelhante em vários sistemas, de modo que não é uma boa ideia que qualquer senha seja legível para humanos. Como alguns sysadmin podem tentar novamente em outros sistemas, ele sabe que o usuário tem uma conta.

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

    

Answer 4

A razão básica (por que isso é uma má idéia) é que nenhum usuário (root, admin ou outro) deve ter acesso à senha do usuário de outra pessoa.

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 o login como aquele usuário , se passando por ele (ou ela).

Qualquer ação que eu fizer quando fizer login como aquele usuário, o outro usuário será responsável por. 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 onde eu (o administrador) tenha acesso a todas as senhas. Usando a senha do caixa, posso pedir um lance de 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 conta bancária off-shore.

Então eu faço longas férias nas Bahamas ...

Nesse ponto de vista, o hashing das senhas e o uso de arquivos shadow separados podem ser vistos como um meio de impor essa regra (nenhum usuário deve ser capaz de se passar por outro).

E como @ Miral's comentou ^* , há a exceção de su que, embora permitindo a representação (e os tipos de rejeita o argumento acima), também mantém um log de seu uso ele altera as regras para "apenas os administradores podem representar outros, mas um log é mantido").

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