sha512crypt et /etc/shadow : comment Linux stocke votre mot de passe

Ouvrez /etc/shadow sur n'importe quelle machine Linux et vous regardez la dernière ligne de défense de chaque compte local. C'est le fichier que vise un attaquant après une prise de pied, parce que tout ce qu'il faut pour casser les mots de passe hors ligne tient au même endroit. Comprendre chaque champ fait la différence entre savoir que vous tenez un sha512crypt à 5000 rounds bon pour le GPU, et ne pas savoir ce que vous regardez.

La ligne shadow, champ par champ

Chaque entrée est séparée par des deux-points et ressemble à ceci :

root:$6$xQ9Hk2pL$Hf3...tronque...0:19876:0:99999:7:::

Le premier champ est le nom d'utilisateur. Le deuxième est le hash du mot de passe, et c'est lui qui compte. Le reste, ce sont des métadonnées de vieillissement : jours depuis le dernier changement, âge minimum et maximum, période d'avertissement, fenêtre d'inactivité. Rien de tout cela ne protège le hash. Si l'attaquant peut lire ce champ, les champs de dates ne servent à rien.

Le champ du hash est lui-même structuré. Ce n'est pas un bloc opaque, c'est $id$rounds$sel$empreinte, séparé par des dollars, et il se lit de gauche à droite.

Le $6$ révèle l'algorithme

L'identifiant entre la première paire de dollars est le schéma. $6$ désigne sha512crypt, valeur par défaut de presque toutes les distributions grand public depuis une décennie. On croise encore du $1$, c'est-à-dire md5crypt, l'ancien défaut qui aurait dû disparaître depuis longtemps. $5$ est sha256crypt, l'enfant du milieu rarement utilisé. $2a$ ou $2b$ désigne bcrypt. $y$ désigne yescrypt, vers lequel les distributions modernes se dirigent.

Avant toute chose, lisez le préfixe. Un hash $6$ correspond au mode 1800 dans hashcat. Un hash $1$ correspond au mode 500. Se tromper là-dessus gâche une session entière.

Les rounds, et le défaut que tout le monde oublie de relever

sha512crypt n'est pas un simple appel à SHA-512. C'est une construction volontairement lente qui exécute le hash sous-jacent des milliers de fois. Le nombre d'itérations est le paramètre rounds=, et s'il n'apparaît pas, c'est le défaut qui s'applique.

Ce défaut, c'est 5000 rounds. Quand le champ affiche $6$rounds=100000$sel$empreinte, quelqu'un l'a relevé volontairement. La grande majorité des fichiers shadow que vous croiserez utilisent le 5000 silencieux, parce que presque personne ne touche à la configuration de crypt. Vous pouvez le relever dans /etc/login.defs via SHA_CRYPT_MIN_ROUNDS, et sur un schéma lent comme celui-ci, augmenter les rounds est le gain défensif le moins cher qui existe. Cela ne fait rien pour un mot de passe faible, mais cela augmente linéairement le coût par essai pour l'attaquant.

Le sel fait son travail, puis s'arrête

Chaque hash sha512crypt porte un sel propre à l'entrée, le morceau entre les rounds et l'empreinte. Il fait exactement ce qu'un sel doit faire : il tue les rainbow tables et garantit que deux utilisateurs au même mot de passe obtiennent des hash différents. Ce qu'il ne fait pas, c'est ralentir un essai isolé. Le sel déjoue le précalcul, pas le débit. Cette distinction est la raison d'être des rounds.

Plus lent que SHA-512 brut, plus faible que bcrypt

Le positionnement honnête, le voici. sha512crypt vaut bien mieux qu'un SHA-512 nu du mot de passe, parce que 5000 itérations transforment un algorithme à un milliard d'essais par seconde en quelque chose qui se compte en bas millions au plus. Mais il a une faiblesse structurelle que bcrypt et argon2id n'ont pas : il n'est pas dur en mémoire. Il tient sans peine dans les registres d'un GPU, donc l'attaquant le parallélise sur des milliers de cœurs pour pas cher. bcrypt a été conçu pour être hostile au cache, et c'est précisément pourquoi bcrypt résiste aux GPU là où sha512crypt n'y parviendra jamais. Argon2id va plus loin et exige de la vraie mémoire par essai. sha512crypt reste au milieu : ni rapide, ni dur.

C'est pourquoi les distributions modernes migrent vers yescrypt par défaut. Il est dur en mémoire, c'est le nouveau préfixe $y$, et il referme l'écart GPU que sha512crypt laisse béant.

Le casser : unshadow et mode 1800

Pour John the Ripper, on fusionne d'abord /etc/passwd et /etc/shadow, parce que John veut les deux :

unshadow /etc/passwd /etc/shadow > hashes.txt
john --wordlist=rockyou.txt hashes.txt

Pour hashcat, pas besoin d'unshadow. Extrayez le champ du hash de la ligne shadow, mettez-le dans un fichier et lancez le mode 1800 :

hashcat -m 1800 -a 0 hashes.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Passons à la réalité du débit. Sur un seul GPU moderne, vous obtenez quelques milliers à quelques dizaines de milliers d'essais par seconde contre du sha512crypt à 5000 rounds. C'est glacial face aux milliards par seconde sur MD5. Une liste de 14 millions de mots avec un jeu de règles lourd ne finira jamais ici. La stratégie doit changer : des listes petites, triées, ciblées, avec des règles légères, exactement comme le décrit le guide des wordlists et des règles. On jette tout sur un hash rapide. On manie le scalpel sur celui-ci.

Ce qu'il faut retenir côté défense

Si vous administrez des systèmes Linux, deux choses pèsent vraiment, et aucune n'est exotique. Poussez la longueur des mots de passe, car la longueur bat tous les jeux de règles et tous les masques d'un attaquant. Et utilisez un schéma moderne : préférez yescrypt là où votre distribution le propose, relevez largement les rounds de sha512crypt au-delà de 5000 si vous y restez, et ne laissez jamais survivre un $1$ md5crypt à une migration. Le hash dans le fichier shadow ne vaut que par le mot de passe derrière lui et l'algorithme qui l'enveloppe.