Pourquoi l'autorisation de fichier pour / etc / shadow est-elle définie sur 600?

Pour empêcher les attaques par force brute hors connexion.

Même si vous ne pouvez pas inverser un hachage, vous pouvez toujours essayer de hacher tous les mots de passe possibles jusqu'à ce que vous trouviez une correspondance, et vous pouvez faire des millions d'essais par seconde avec un bon matériel et un accès local au fichier.

Si le fichier avait les autorisations 644 , toute personne connectée à votre système, même en session invité, pourrait copier ce fichier hors de votre ordinateur (que ce soit sur un périphérique USB). coller ou à distance via scp ) et tenter une attaque par force brute hors connexion, sans en laisser aucune preuve sur votre ordinateur .

Notez que les autorisations sur Ubuntu sont en réalité 640 , et non 600 :

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1239 Jun 25 04:35 /etc/shadow

Cela n’importe pas grand-chose, car il n’ya toujours pas d’autorisations pour les autres, et, par défaut, personne ne se trouve dans le groupe shadow .

A l'origine, les hachages étaient stockés dans /etc/passwd (c'est pourquoi ils sont appelés passwd ), car à la création de Linux, le craquage d'un hachage, même les types faibles utilisés à l'époque, était pratiquement impossible. Finalement, la puissance de traitement est devenue telle que le craquage d’un hachage, au moins d’un mot de passe relativement faible, est devenu réalisable.

Changer les permissions de /etc/passwd à 640 ou 600 ne fonctionnerait pas, car il existe de nombreuses raisons légitimes de pouvoir lire /etc/passwd en tant qu'utilisateur normal (conversion des UID en noms d'utilisateur, obtention d'un utilisateur) le nom complet, le numéro de téléphone, etc.), ainsi les mots de passe ont été déplacés vers /etc/shadow , avec les autorisations 640 . Un x à la place du champ de hachage de mot de passe pour un utilisateur dans /etc/passwd est utilisé pour indiquer que le hachage pour cet utilisateur est plutôt stocké dans /etc/shadow .

En fait, / etc / shadow a été créé pour permettre d’éloigner de une liste de noms d’utilisateur et de mots de passe lisibles publiquement.

Attendez, ce sera un peu une leçon d’histoire, avant d’arriver à la réponse. Si vous ne vous souciez pas de l’histoire, faites défiler un peu.

Autrefois, les systèmes d'exploitation de type Unix, y compris Linux, conservaient généralement tous les mots de passe dans / etc / passwd. Ce fichier était lisible par tous les utilisateurs et l'est toujours, car il contient des informations permettant par exemple de mapper des identifiants d'utilisateurs numériques et des noms d'utilisateur. Cette information est très utile, même pour les utilisateurs ordinaires, à des fins parfaitement légitimes. Il est donc très utile d’avoir un fichier lisible dans le monde entier.

Même à l’époque, les gens se sont rendu compte qu’avoir les mots de passe en texte clair dans un fichier dans un endroit connu que toute personne pouvant se connecter pouvait lire librement était une mauvaise idée. Les mots de passe ont donc été hachés, dans un sens. C'est le vieux mécanisme de hachage de mot de passe «crypt», qui n'est presque jamais utilisé sur les systèmes modernes, mais souvent pris en charge à des fins héritées.

Regardez / etc / passwd sur votre système. Voir ce deuxième champ, qui dit x partout? Il contenait le mot de passe haché du compte en question.

Le problème était que les gens pouvaient télécharger / etc / passwd, ou même ne pas le télécharger, et travailler à déchiffrer les mots de passe. Ce n'était pas un gros problème alors que les ordinateurs n'étaient pas particulièrement puissants (Clifford Stoll, dans The Cuckoo's Egg , donne, si je me souviens bien, le temps de hacher un mot de passe sur un système IBM PC class environ une seconde au milieu des années 1980), mais la capacité de traitement s’est accrue. À un moment donné, avec une liste de mots décente, il était trop facile de déchiffrer ces mots de passe. Pour des raisons techniques, ce schéma ne pouvait pas non plus prendre en charge les mots de passe de plus de huit octets.

Deux choses ont été faites pour résoudre ce problème:

• Passer à des fonctions de hachage plus fortes. L'ancienne crypt () avait dépassé sa durée de vie utile, et des schémas plus modernes, à la fois pérennes et calculables, ont été mis au point.
• Déplacez les mots de passe hachés dans un fichier illisible par n'importe qui. De cette façon, même si une fonction de hachage de mot de passe s'avérait plus faible que prévu ou si quelqu'un avait un mot de passe faible pour commencer, un attaquant avait un autre obstacle pour accéder aux valeurs de hachage. Ce n'était plus gratuit pour tous.

Ce fichier est / etc / shadow.

Le logiciel qui fonctionne avec / etc / shadow est généralement très petit, très ciblé et a tendance à recevoir un examen plus approfondi en raison des problèmes potentiels. Il fonctionne également avec des autorisations spéciales, ce qui lui permet de lire et de modifier / etc / shadow, tout en empêchant les utilisateurs ordinaires d’examiner ce fichier.

Donc là vous l'avez: Les autorisations sur / etc / shadow sont restrictives (bien que, comme déjà indiqué, ce n'est pas tout à fait aussi restrictif que vous le dites) car le but de ce fichier est de restreindre l'accès aux fichiers sensibles. données.

Un hachage de mot de passe est supposé être puissant, mais si votre mot de passe se trouve sur les listes Top 500 mots de passe sur Internet , toute personne ayant accès au hachage pourra toujours trouver le mot de passe rapidement. Protéger le hachage empêche cette attaque simple et fait en sorte que toute attaque réussie, du simple coup d’œil à l’exigence d’être un administrateur système sur l’hôte, ou d’attaques d’élévation de privilèges en premier lieu. Surtout sur un système multi-utilisateurs correctement administré, ces deux problèmes sont significativement plus difficiles que de simplement regarder un fichier lisible dans le monde entier.

  

Pourquoi l’autorisation du fichier / etc / shadow est-elle définie sur 600?

Qui vous a dit ça?

$ls -l /etc/shadow
-rw-r----- 1 root shadow 1407 mei 18 10:05 /etc/shadow

• c'est 640.

Réponse simple: les autorisations sous Linux sont prises au sérieux. Il n'y a aucune raison pour que "les autres" fassent quelque chose avec /etc/shadow . Et il n'y a aucune raison pour que le groupe "shadow" lui écrive. Et l'exécution est hors de l'ordre.

  

Cependant, comme tous les mots de passe ne sont pas stockés en clair mais en tant que hachage (ce qui signifie qu’il est impossible de calculer le mot de passe original à partir du hachage), pourquoi ne pas les lire?

Parce qu’il n’ya pas une seule raison de le faire.

Les hachages sont à sens unique. Donner à quelqu'un un accès en lecture lui permet d'utiliser un script pour abuser de ce sens unique: il suffit de lister les mots que vous pouvez imaginer et de créer le hash. À un moment donné, cela pourrait correspondre au mot de passe. Cela pourrait prendre un peu de temps aussi.

Cette réponse est intéressante et contient des estimations sur le forçage brut.

Arrière-plan important: /etc/shadow existe uniquement dans le but de masquer le hachage du mot de passe. Au début de Unix, les hachages de mots de passe étaient stockés dans /etc/passwd . Les ordinateurs devenant plus puissants, les connexions réseau plus persistantes et les exploits de sécurité plus sophistiqués, les gens se sont rendu compte que garder les mots de passe cryptés lisibles sur les mots demandait des problèmes. (Je ne détaillerai pas les exploits; il y a déjà assez de bonnes réponses à ce sujet.)

Mais /etc/passwd n'a pas pu être protégé en lecture: il est utilisé par toutes sortes de programmes pour mapper les identifiants numériques des utilisateurs vers les noms d'utilisateurs, rechercher les répertoires personnels, les shells par défaut, . - Découvrez man finger ). Ainsi, la partie sensible, le mot de passe haché, a été déplacée vers /etc/shadow et le reste est resté tel quel. C'est pourquoi /etc/passwd , dédaigne le nom, contient tout sauf le mot de passe (haché).