Comment rendre les mots de passe des utilisateurs affichés en texte clair sous Linux?

Question

Nous savons que les mots de passe des utilisateurs sont enregistrés dans /etc/passwd, mais de manière cryptée, donc même la racine ne peut pas les voir:

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

Comme montré ci-dessus, :x: représente le mot de passe.

Existe-t-il un moyen (configuration possible) de sauvegarder le mot de passe dans le /etc/passwd en texte clair et tel que la racine puisse les voir?

derobert · Accepted Answer

Les deux autres réponses vous ont dit - correctement! - que c'est une mauvaise idée ™ . Mais ils vous ont également dit que c'était difficile à faire, nécessitant de changer un tas de programmes.

Ce n'est pas vrai. C'est très facile. Il vous suffit de modifier un ou deux fichiers de configuration. Je pense qu'il est important de le signaler, car vous devez en être conscient lorsque vous vous connectez à des systèmes que vous ne contrôlez pas. Ceux-ci ne mettront pas réellement un mot de passe en texte brut dans /etc/passwd ou /etc/shadow, il ira dans un autre fichier. Notez que je n'ai pas testé ces derniers, car je préfère ne pas avoir mon mot de passe en texte brut.

Éditer /etc/pam.d/common-password (pour saisir le mot de passe modifié) ou /etc/pam.d/common-auth (à attraper lors de la connexion) et ajoutez … pam_exec expose_authtok log=/root/passwords /bin/cat
Modifiez les deux et passez de pam_unix à pam_userdb avec crypt=none. Alternativement, vous pouvez le mettre uniquement dans common-password (en laissant également pam_unix) pour simplement enregistrer les mots de passe lorsqu'ils sont modifiés.
Vous pouvez supprimer l'option shadow (ainsi que toutes les options de hachage fortes) de pam_unix pour désactiver le fichier fantôme et revenir aux mots de passe de cryptage traditionnels. Ce n'est pas du texte brut, mais John l'Éventreur va régler cela pour vous.

Pour plus de détails, consultez le Guide d'administration du système PAM .

Vous pouvez également modifier le code source de PAM ou écrire votre propre module. Il vous suffirait de compiler PAM (ou votre module), rien d'autre.

Bobby · Answer

Oh chérie, d'accord, commençons au tout début ...

Nous savons que les mots de passe des utilisateurs sont enregistrés dans/etc/passwd, mais de manière cryptée

Non, ils ont été stockés dans /etc/passwd, et c'était il y a un certain temps. Aujourd'hui, les mots de passe sont stockés dans un soi-disant fichier caché , la plupart du temps /etc/shadow.

mais de manière cryptée, donc même la racine ne peut pas les voir:

Je sais qu'il est parfois utilisé de manière interchangeable, mais hachage n'est pas cryptage . Le cryptage est par sa définition même réversible, ce qui signifie que vous pouvez traduire la chose cryptée dans sa forme en texte clair. Le hachage est conçu pour être non réversible de quelque manière que ce soit (sauf la force brute). La forme originale en texte clair de quelque chose haché n'est pas censée être récupérable.

Les mots de passe dans le fichier caché sont stockés sous forme de hachages.

comme indiqué ci-dessus: x: représente le mot de passe

Le x dans ce cas n'est qu'un espace réservé pour le champ de mot de passe hérité. x signifie que le mot de passe se trouve dans le fichier shadow.

Existe-t-il un moyen (configuration possible) de sauvegarder le mot de passe dans/etc/passwd en texte clair et tel que la racine puisse les voir?

Oui, c'est en effet possible, mais ce n'est pas une bonne idée pour certaines raisons. La réponse de Derobert explique une manière assez simple de le faire .

Mais pourquoi n'est-ce pas une bonne idée? Eh bien, pour une raison simple mais très importante: la sécurité. Je suggère de lire ces questions:

Mais pour résumer, supposez ce qui suit: Il y a un serveur dans une entreprise, tous les comptes d'utilisateurs sont sécurisés par leurs mots de passe et les données de ces comptes d'utilisateurs sont cryptées avec le même mot de passe. Un pirate de l'extérieur accède au serveur, mais ils ne peuvent accéder à aucune des données importantes car elles sont toujours cryptées dans les comptes d'utilisateurs.

Supposons maintenant que les mots de passe soient stockés en texte brut. Le pirate aurait soudainement accès à tout , car les mots de passe peuvent être lus. Mais s'ils sont stockés sous forme de valeurs hachées, ils sont presque inutiles à quiconque, sauf aux personnes disposant de nombreuses ressources pour effectuer une attaque par force brute.

Anthon · Answer

Tout d'abord, les mots de passe chiffrés ne sont pas dans /etc/passwd, mais ils sont dans /etc/shadow. L'une des raisons à cela est que /etc/passwd est lisible publiquement (vous pouvez par exemple trouver les informations de champ GECOS pour un autre utilisateur) et, en particulier avec les anciens schémas de cryptage, pourrait permettre des attaques par force brute contre le mot de passe crypté.

Pour stocker simplement les mots de passe en texte brut, n'est pas nécessaire et nécessiterait des mises à jour du programme de mot de passe et des bibliothèques lisant le /etc/shadow informations pour vérifier les mots de passe valides. Et puis vous devez espérer que tous les utilitaires utilisent des bibliothèques partagées pour accéder à ces informations au lieu d'être liés statiquement à quelque chose qui ne comprend pas le stockage de mots de passe en texte brut.

Si cela était une option dans la configuration d'une configuration, alors il y aurait toujours des gens stupides qui allumeraient de manière inappropriée. Et alors qu'ils travaillent toujours sur des écrans CRT et diffusent cela de manière à ce qu'ils puissent être facilement récupérés de l'extérieur de leur bâtiment, alors qu'ils regardent les informations.

En dehors de cela, les gens ont tendance à utiliser le même mot de passe ou un mot de passe similaire sur plusieurs systèmes, ce n'est donc pas une bonne idée que les mots de passe soient lisibles par l'homme. Étant donné que certains administrateurs système peuvent réessayer sur d'autres systèmes, il sait que l'utilisateur possède un compte.

Il doit y avoir des choses plus intéressantes, le fonctionnement de peut être étudié sur votre système.

ypercubeᵀᴹ · Answer

La raison fondamentale (pourquoi c'est une mauvaise idée) est qu'aucun utilisateur (root, admin ou autre) ne devrait jamais avoir accès au mot de passe d'un autre utilisateur.

Tout simplement parce que le mot de passe est un moyen d'authentification. Si je connais le mot de passe d'un autre utilisateur, je connais ses identifiants (nom d'utilisateur + mot de passe), donc je peux me connecter en tant qu'utilisateur, usurper l'identité de lui (ou de lui).)

Toute action que je fais lorsque je suis connecté en tant qu'utilisateur, l'autre utilisateur sera tenu responsable. Et ce n'est pas ainsi que l'authentification devrait fonctionner.

Les actions peuvent être désastreuses, comme la suppression d'un tas de fichiers importants, l'effacement des disques durs, l'effacement des sauvegardes, l'arrêt des plans d'énergie nucléaire, etc.

Ou tout simplement illégal. Imaginez une institution bancaire où moi (l'administrateur) ai accès à tous les mots de passe. En utilisant le mot de passe du caissier, je peux commander un transfert d'un million de dollars du compte bancaire du président vers le compte bancaire du nettoyeur de vitres. Utilisez ensuite le mot de passe supérieur du caissier pour approuver la transaction. Approuvez ensuite un chèque du compte du nettoyeur de vitres à mon propre compte bancaire offshore.

Ensuite je pars pour de longues vacances aux Bahamas ...

Dans cette vue, le hachage des mots de passe et l'utilisation de fichiers fantômes distincts peuvent être considérés comme un moyen d'appliquer cette règle (aucun utilisateur ne devrait pouvoir se faire passer pour un autre).

Et comme l'a commenté @ Miral^*, il y a l'exception de su qui, tout en permettant l'emprunt d'identité (et les types de rejet de l'argument ci-dessus), conserve également un journal de son utilisation (il modifie donc les règles en "seuls les administrateurs peuvent emprunter l'identité des autres, mais un journal est conservé ").

^{* L'exemple bancaire n'était probablement pas le meilleur. Dans tout environnement où la sécurité est cruciale, plus de moyens d'authentification et d'autorisation sont généralement nécessaires qu'un seul mot de passe.}