Vos rôles PostgreSQL stockent-ils encore des hachages MD5 ?
Avec PostgreSQL 18, le message est clair : le hachage MD5 pour les mots de passe est déprécié. Un nouveau paramètre, md5_password_warnings, permet de contrôler l'avertissement associé. Avant de le désactiver par réflexe, mieux vaut comprendre ce qu'il signale et ce qu'il masque. Cet article s'appuie sur l'analyse publiée par Christophe Pettus : Christophe Pettus: All Your GUCs in a Row: md5_password_warnings.
Ce que fait réellement ce paramètre
md5_password_warnings est un booléen, activé par défaut. Son rôle se limite à couper (ou non) l'avertissement de dépréciation émis par le serveur. Il ne change rien au comportement de l'authentification.
Quelques points à retenir :
- Son contexte est
user : n'importe quel rôle peut le désactiver pour sa propre session, sans privilège particulier.
- Il n'existe pas avant PostgreSQL 18.
- Un serveur 16 qui le trouve dans
postgresql.conf refuse de démarrer.
Ce dernier point mérite attention si vous utilisez un même modèle de configuration pour un parc mixte de versions. Une ligne ajoutée trop tôt peut empêcher un redémarrage.
Pourquoi MD5 pose problème
MD5 n'est plus considéré comme une fonction de hachage sérieuse depuis longtemps. Mais l'usage qu'en fait PostgreSQL ajoute une faiblesse propre : le hachage stocké dans pg_authid suffit à lui seul pour s'authentifier. Autrement dit, un attaquant qui le vole n'a pas besoin de le casser, car le hachage joue le rôle du mot de passe.
SCRAM-SHA-256 corrige cette situation. Il est disponible depuis PostgreSQL 10 et valeur par défaut de password_encryption depuis la version 14. Côté calendrier, une feuille de route de retrait a été proposée sur la liste pgsql-hackers en octobre 2024, et la dépréciation a été validée en décembre de la même année.
Quand l'avertissement se déclenche
En version 18, l'avertissement apparaît à un seul endroit : lorsqu'un CREATE ROLE ou un ALTER ROLE enregistre un hachage MD5.
SET password_encryption = md5;
CREATE ROLE legacy_app LOGIN PASSWORD 'secret';
-- WARNING: setting an MD5-encrypted password
-- DETAIL: MD5 password support is deprecated and will be removed
-- in a future release of PostgreSQL.
La vérification porte sur ce qui est stocké, pas sur la valeur de password_encryption. Fournir un mot de passe déjà haché au format md5... déclenche donc aussi l'avertissement, même avec le réglage par défaut scram-sha-256.
Le paramètre vise ainsi les personnes qui créent ou modifient des rôles. Il ne signale pas, à lui seul, les rôles existants dont le hachage MD5 dort dans le catalogue. C'est un détail important : l'absence de message ne prouve pas l'absence de MD5 dans votre base.
Plan d'action pour une migration sereine
Plutôt que de couper l'avertissement, utilisez-le comme signal pour auditer votre parc.
1. Vérifier la configuration
Contrôlez la valeur de password_encryption sur chaque instance. Elle doit valoir scram-sha-256, ce qui est le cas par défaut depuis PostgreSQL 14 sauf configuration contraire.
SHOW password_encryption;
2. Repérer les rôles concernés
Le catalogue pg_authid (accessible aux superutilisateurs) contient les hachages. Un mot de passe MD5 y commence par le préfixe md5, un mot de passe SCRAM par SCRAM-SHA-256.
SELECT rolname
FROM pg_authid
WHERE rolpassword LIKE 'md5%';
3. Réinitialiser les mots de passe
On ne peut pas convertir un hachage MD5 en SCRAM : il faut redéfinir le mot de passe avec la bonne configuration active.
SET password_encryption = 'scram-sha-256';
ALTER ROLE legacy_app PASSWORD 'nouveau_mot_de_passe';
4. Vérifier les clients et intermédiaires
Avant de basculer, assurez-vous que vos pilotes, vos outils et votre pooler de connexions gèrent SCRAM. L'article source rappelle par exemple que PgBouncer peut se connecter à un serveur en MD5 avec un simple fichier d'authentification contenant des hachages MD5, ce qui illustre bien le problème : ce fichier devient un identifiant utilisable tel quel. Pensez à mettre à jour ces fichiers et leur format en même temps que les rôles.
5. Régler pg_hba.conf
Une fois la migration terminée, remplacez la méthode md5 par scram-sha-256 dans pg_hba.conf pour interdire le retour en arrière.
Faut-il désactiver l'avertissement ?
Pendant une migration progressive, désactiver md5_password_warnings sur une session ciblée (un script de provisionnement, par exemple) peut éviter du bruit dans les logs. Mais le désactiver globalement revient à éteindre le voyant d'alerte d'un tableau de bord alors que le moteur chauffe. La dépréciation annonce un retrait futur : les rôles encore en MD5 deviendront alors inutilisables.
Conclusion
md5_password_warnings est un interrupteur, pas une solution. Le vrai chantier consiste à recenser les rôles encore en MD5, à réinitialiser leurs mots de passe en SCRAM-SHA-256, puis à verrouiller pg_hba.conf. Si vous préparez une montée vers PostgreSQL 18, ajoutez cet audit à votre checklist de migration, et gardez en tête que le paramètre n'existe pas sur les versions antérieures lorsque vous partagez des fichiers de configuration entre environnements.
