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

28

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?

password

— user78050
source

10

Et c'est une fonctionnalité. Il n'y a pas non plus de raison réelle car le compte root n'a pas besoin du mot de passe d'un utilisateur pour accéder à ses fichiers. Dans quelles circonstances voudriez-vous cela?

— HalosGhost

1

Je suis juste curieux à ce sujet, pourquoi l'administrateur (la racine) du système ne peut-il pas voir les mots de passe des autres utilisateurs?

— user78050

5

@ user78050 car l'utilisateur root n'a aucune raison de connaître les mots de passe des autres utilisateurs, et ce serait un risque de sécurité majeur de leur permettre de le faire.

— David Z

16

Parce qu'il viole le principe de sécurité le plus simple de l'entreprise: "ne stockez jamais les mots de passe en texte brut". Lorsque la sécurité est bien faite, seul l'utilisateur doit connaître son mot de passe, personne d'autre. De plus, il n'y a absolument aucune raison de le faire. Je ne peux pas penser à une seule situation administrative où cela aiderait un utilisateur root à connaître le mot de passe d'un autre utilisateur.

— HalosGhost

3

Utilisez la «méthode de chiffrement» MD5, puis déchiffrez les mots de passe à l'aide de tables arc-en-ciel .

— Cristian Ciupitu

58

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.

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
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.
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.

— derobert
source

1

Je suppose que les mots de passe en texte brut sont écrits /root/passwords.

— Faheem Mitha

Btw. très bon de savoir à quel point c'est facile et où je dois regarder si j'ai peur d'un système compromis.

— erik

8

@erik C'est la prérogative du demandeur de choisir la réponse qu'il / elle trouve la plus utile comme réponse acceptée. C'est probablement une bonne chose qu'OP ait trouvé "ne fais pas ça!" le plus utile… De plus, pour être clair, ce n'est pas le seul moyen de voler des mots de passe sur un système compromis ou malicieusement administré. Vous ne pouvez donc pas simplement regarder la configuration PAM pour déterminer que vous êtes en sécurité.

— derobert

3

C'est plutôt en supposant que la distribution utilise PAM, en aucun cas tous le font.

— Vality

1

@msw J'ai répondu parce que c'est apparemment une croyance commune selon laquelle exécuter une boîte Linux avec des mots de passe en texte clair est difficile (Bobby, à son crédit, a corrigé sa réponse; Anthon a toujours du mal à le faire). C'est une croyance dangereuse, car elle encourage la réutilisation du mot de passe. Si je venais de poster une réponse "en fait, c'est facile, vous modifiez un fichier ou deux, mais je ne vous le dirai pas", alors personne n'aurait cru cela. Pourquoi m'écouter sur les réponses (à l'époque) beaucoup plus votées et plus approfondies? Faire le point nécessite de dire comment le faire. (Cependant, ce ne sont pas des exemples de copier-coller. La pensée est toujours requise pour utiliser.)

— derobert

34

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:

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.

— Policier
source

2

Dans la défense d'OP concernant le chiffrement et le hachage, la page de manuel de crypt de la glibc dit: «Si le sel est une chaîne de caractères commençant par les caractères "$id$"suivis d'une chaîne terminée par "$": $id$salt$encrypted alors au lieu d'utiliser la machine DES, ididentifie la méthode de chiffrement utilisée et ceci ensuite détermine comment le reste de la chaîne est interprété ».

— Cristian Ciupitu

1

Intéressant, mais ne répond pas à la question principale, comme le fait la réponse de Derobert.

— erik

6

@erik Parfois, la bonne réponse à une question est «ne le faites pas», même lorsque la chose est techniquement possible. C'est l'une de ces fois.

— Gilles 'SO- arrête d'être méchant'

1

Je suggère de changer cette ligne: "Non, il n'y a pas d'autre moyen que de changer de nombreuses applications et la façon dont elles fonctionnent." Cela donne l'impression que ce n'est pas facile (ou du moins facile de faire quelque chose de fonctionnellement équivalent).

— derobert

2

@Bobby C'est une excellente réponse, mais pas une excellente réponse. Pour en faire une excellente réponse, vous devriez changer la partie sur le fait qu'il n'est "pas facilement possible", car c'est clairement le cas, comme le montre la réponse de derobert.

— Michael Dorst

10

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.

— Anthon
source

3

/etc/shadowne stocke pas les mots de passe cryptés, il stocke les hachages de mot de passe. Oui, la fonction est appelée cryptet la page de manuel indique «crypté», mais si vous appelez un poisson un vélo, cela ne lui donne pas de roues. Notez qu'il serait possible de créer /etc/shadowdes mots de passe de stockage dans un format différent sans recompiler aucun programme (au moins sous Linux et Solaris): les méthodes d'authentification sont toujours liées dynamiquement. Stocker des mots de passe en texte brut serait une idée terrible mais cela est possible avec un peu de travail .

— Gilles 'SO- arrête d'être méchant'

@gilles Je viens de réutiliser la terminologie OP, mais vous avez raison de dire que le hachage est un terme plus approprié.

— Anthon

3

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.}

— ypercubeᵀᴹ
source

Un défaut de cet argument est que l'utilisateur root peut de toute façon se faire passer pour n'importe quel autre utilisateur du système, sans avoir à connaître son mot de passe. Aussi simple que su otheruser.

— Miral

@Miral tu as raison, je n'y ai pas pensé. Et bien que l'utilisation de susoit enregistrée, su ne conserve pas d'enregistrement de ce qui est réellement fait pendant qu'un utilisateur usurpe l'identité d'un autre. Et une racine malveillante peut toujours modifier les journaux pour masquer les actions des futurs enquêteurs.

— ypercubeᵀᴹ