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

Nous savons que les mots de passe des utilisateurs sont enregistrés /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 indiqué ci-dessus, :x:représente le mot de passe.

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

Les deux autres réponses vous ont dit - correctement! - qu'il s'agit d'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 /etc/passwdou /etc/shadow, ils iront dans un fichier différent. Notez que je ne les ai pas testés, car je préfère ne pas avoir mon mot de passe en texte brut.

1. Modifier /etc/pam.d/common-password(pour attraper le mot de passe modifié) ou /etc/pam.d/common-auth(pour attraper sur la connexion) et ajouter… pam_exec expose_authtok log=/root/passwords /bin/cat

2. Modifiez les deux et passez de pam_unix à pam_userdb avec crypt=none. Alternativement, vous pouvez le mettre uniquement dans le mot de passe commun (en laissant également pam_unix) pour simplement enregistrer les mots de passe lorsqu'ils sont modifiés.

3. Vous pouvez supprimer l' shadowoption (ainsi que toutes les options de hachage puissantes) de pam_unix pour désactiver le fichier caché 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.

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 qui était tout à fait il y a quelque 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 le hachage n'est pas du 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 ne pas être réversible en aucune façon (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

Dans xce cas, il s'agit uniquement d'un espace réservé pour le champ de mot de passe hérité. Les xmoyens que le mot de passe peut être trouvé dans le fichier d'ombre.

Existe-t-il un moyen (configuration possible) d'enregistrer 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:

• Quelle est une bonne analogie pour expliquer pourquoi les mots de passe doivent être hachés à un profane?
• Comment hacher en toute sécurité les mots de passe?
• Pourquoi devrais-je hacher les mots de passe?
• Pourquoi le hachage de mot de passe est-il si important?
• Pourquoi les fonctions de hachage sont-elles à sens unique? Si je connais l'algorithme, pourquoi ne puis-je pas calculer son entrée?

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.

Tout d'abord, les mots de passe cryptés ne sont pas disponibles /etc/passwd, mais ils le sont /etc/shadow. L'une des raisons à cela est qu'elle /etc/passwdest 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 les /etc/shadowinformations 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 devait être 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. Comme 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.

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 informations d'identification (nom d'utilisateur + mot de passe), donc je peux me connecter en tant qu'utilisateur , en usurpant son identité (ou 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 de disques durs, l'effacement de sauvegardes, l'arrêt de 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 suqui, tout en permettant l'emprunt d'identité (et les types de rejet de l'argument ci-dessus), tient également un journal de son utilisation (il modifie donc les règles en "seuls les administrateurs peuvent usurper 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.}