Définir l'algorithme de hachage des mots de passe PAM - password-auth
Force PAM (pam_unix.so) à hacher les mots de passe utilisateur avec un algorithme robuste, yescrypt ou sha512, au lieu d'un schéma ancien et faible.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Les mots de passe stockés ne sont protégés que par la robustesse de l'algorithme de hachage. Les schémas faibles (DES, MD5) sont rapides à forcer par force brute et facilement cassés à partir d'un /etc/shadow divulgué, mettant en danger tous les comptes. Les algorithmes modernes, yescrypt (défaut sur Debian/Ubuntu) et sha512, sont lents et salés, augmentant fortement le coût d'un cassage hors ligne. Configurer pam_unix.so pour les utiliser garantit que tout mot de passe défini ou modifié est stocké avec une protection forte.
Ce que vérifie Pavois
Pavois recherche dans la pile PAM active sous /etc/pam.d/ une ligne pam_unix.so portant sha512 ou yescrypt. PAM est le composant qui calcule réellement le hachage lors de la définition d'un mot de passe ; vérifier sa configuration capture donc la politique qui sera appliquée, plus fiable que de deviner à partir des hachages déjà stockés, qui ne reflètent que les changements passés.
describe command('grep -qrE \'pam_unix.so.*(sha512|yescrypt)\' /etc/pam.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez grep -rE 'pam_unix.so.*(sha512|yescrypt)' /etc/pam.d/. La sortie attendue est au moins une ligne password correspondante (par ex. password ... pam_unix.so ... yescrypt). Vous pouvez aussi vérifier le hachage d'un compte réel avec getent shadow root, un préfixe $y$ indique yescrypt, $6$ indique sha512.
Inspecter et investiguer
Les changements de mot de passe sont enregistrés via journalctl et /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). passwd et PAM y émettent des entrées à chaque mise à jour ; le format de hachage résultant est visible dans /etc/shadow.
Remédiation
Aucun plan de durcissement automatisé n'est défini ; cela doit donc être appliqué manuellement : assurez-vous que la ligne password de pam_unix.so dans /etc/pam.d/common-password (Debian/Ubuntu) ou dans les fichiers password-auth/system-auth (RHEL) inclut yescrypt ou sha512, et sur RHEL fixez la valeur par défaut globale via authselect ou /etc/login.defs (ENCRYPT_METHOD SHA512/YESCRYPT).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Ensure pam_unix uses a strong hash. Preferred: set in /etc/login.defs: ENCRYPT_METHOD YESCRYPT # (pavois's logindefs-encrypt_method does this). If the benchmark requires the option on the PAM # line, add 'yescrypt' to the pam_unix.so line in /etc/pam.d/common-password (via pam-auth-update). |
|---|---|
| reason | changing the pam_unix hashing option edits the PAM stack, apply via pam-auth-update / review |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Changer l'algorithme de hachage ne rehache pas les mots de passe existants, ils conservent leur ancien format jusqu'au prochain changement par chaque utilisateur ; prévoyez donc une rotation des mots de passe lors d'une migration depuis un schéma faible. Le changement lui-même est sans danger pour les sessions actives. Évitez de supprimer entièrement la ligne password ou de mal saisir la pile PAM, car un fichier pam.d cassé peut bloquer les connexions ; testez dans une session console avant de fermer votre seul accès.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R68 | direct | 2.0 | haute |
| CIS | 5.3.3.4.3, 8.3.2 | direct | per OS, see the benchmark table | haute |
| NIST | 3.13.11, CM-6(a), IA-5(1)(c), IA-5(c) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 8.3.2 | support | 4.0.1 | moyenne |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.