Na verdade, o / etc / shadow foi criado para permitir afastar-se de uma lista publicamente legível de nomes de usuário e senhas.
Espere aí, isso será um pouco de uma lição de história, antes de chegarmos à resposta real. Se você não se importa com a história, basta rolar um pouco para baixo.
Antigamente, os sistemas operacionais do tipo Unix, incluindo Linux, geralmente mantinham as senhas em / etc / passwd. Esse arquivo era legível mundialmente e ainda é, porque contém informações que permitem o mapeamento, por exemplo, entre IDs numéricos e nomes de usuários. Essas informações são altamente úteis, mesmo para usuários comuns, para fins perfeitamente legítimos; portanto, ter o mundo dos arquivos legível foi de grande benefício para a usabilidade.
Mesmo naquela época, as pessoas percebiam que ter as senhas em texto sem formatação em um arquivo em um local conhecido que qualquer pessoa que pudesse fazer login pudesse ler livremente era uma má idéia. Então, as senhas foram hash, em certo sentido. Esse é o antigo mecanismo de hash de senha "crypt", que quase nunca é usado em sistemas modernos, mas geralmente é suportado para fins legados.
Dê uma olhada em / etc / passwd no seu sistema. Veja esse segundo campo, que diz em xtoda parte? Ele costumava conter a senha com hash da conta em questão.
O problema era que as pessoas podiam fazer o download do / etc / passwd ou até mesmo não fazer o download e trabalhar para decifrar as senhas. Este não foi um grande problema, enquanto os computadores não eram particularmente poderosos (Clifford Stoll, em The Cuckoo's Egg , dá, pelo que me lembro, o tempo para colocar uma senha em um sistema de classe de PC IBM em meados da década de 1980, em meados da década de 1980, em cerca de um segundo. ), mas tornou-se um problema à medida que o poder de processamento aumentava. Em algum momento, com uma lista decente de palavras, a quebra dessas senhas se tornou muito fácil. Por razões técnicas, esse esquema também não suporta senhas com mais de oito bytes.
Duas coisas foram feitas para resolver isso:
- Movendo-se para funções de hash mais fortes. A antiga cripta () sobreviveu à sua vida útil, e foram criados esquemas mais modernos, que eram à prova de futuro e computacionalmente mais fortes.
- Mova as senhas com hash para um arquivo que não possa ser lido por ninguém. Dessa maneira, mesmo que a função de hash da senha tenha sido mais fraca do que o esperado, ou se alguém tivesse uma senha fraca, havia outro obstáculo para um invasor obter acesso aos valores de hash. Não era mais gratuito para todos.
Esse arquivo é / etc / shadow.
O software que trabalha com / etc / shadow geralmente é muito pequeno, altamente focado e tende a receber algum exame extra nas revisões devido ao potencial de problemas. Também é executado com permissões especiais, o que permite ler e modificar / etc / shadow, mantendo os usuários comuns incapazes de ver esse arquivo.
Então, já está: As permissões no / etc / shadow são restritivas (embora, como já apontado, não sejam tão restritivas quanto você afirma), porque o objetivo desse arquivo é restringir o acesso a dados confidenciais.
Um hash de senha deve ser forte, mas se sua senha estiver entre as 500 principais senhas nas listas da Internet , qualquer pessoa com acesso ao hash ainda poderá encontrar a senha rapidamente. Proteger o hash evita esse ataque simples e eleva a barreira para um ataque bem-sucedido, desde a simples espionagem até a exigência de que você já seja um administrador de sistemas no host ou passe primeiro por um ataque de escalação de privilégios. Especialmente em um sistema multiusuário administrado corretamente, ambos são significativamente mais difíceis do que apenas olhar para um arquivo legível pelo mundo.
/etc/shadowsão600?