Vous n'êtes pas identifié(e).
Bonjour à tous,
Je teste actuellement une montée en version de postgresql sur un serveur non en production.
Je me confronte au problème d'encryption des mots de passe.
Dans ma procédure de migration , je commence par réinjecter tous les comptes (en provenance d'un postgresql 12 donc encrypté en md5)
puis je restaure ensuite chacune des bases une a une.
Mon problème est simple y-a-t-il une méthode qui permet lors de la migration (je fabrique un fichier .dump pour stocker les comptes) que je relis afin de le réinjecter dans la version 14 qui permet de hasher les mots de passe avec la nouvelle méthode?
Dans mon cas je n'upgrade pas un serveur en place mais je renvoie la derniere sauvegarde fiable sur une nouvelle version (ce qui permet de partir sur une configuration logicielle et matérielle plus récente).
D'avance merci pour vos éclairages!
Bonne soirée!
Hors ligne
Non, les mots de passe sont exportés avec leur hachage MD5. Il n'est pas possible de revenir vers la version non hachée, et donc impossible de calculer le nouveau hachage avec SCRAM.
Guillaume.
Hors ligne
Bonjour Guillaume,
Merci pour ces éléments de réponses.
Je conclus donc que dans mon cas de figure :
soit je remets la valeur md5 dans password_encryption dans le postgresql.conf du postgresql 14.
Soit je ne transfert pas ma base de compte et je ressaisis ou fait ressaisir tous les mots de passe par les utilisateurs.
J'espère que ma synthése est juste?
Bonne journée
Hors ligne
Le fait de mettre password_encryption scram-sha-256 signifie que les mots de passe saisis à compter du changement seront encodés en scram-sha-256. Ca n'a pas d'effet sur l'acceptation ou pas des connexions de comptes avec des mots de passe déjà existants en md5, et donc il n'y pas d'intérêt particulier à rétrograder password_encryption sur postgresql 14.
Sauf si vous avez des vieux clients SQL qui ne savent pas faire du SCRAM (par exemple driver JDBC avant la version 42.2) et que vous ne pouvez pas les mettre à jour. Dans ce cas il faut que tous les comptes anciens comme nouveaux soient en md5, donc password_encryption=md5 obligatoire.
En revanche dans pg_hba.conf si on met scram-sha-256 comme méthode, on exprime que c'est le minimum acceptable. Les comptes qui ont des mots de passe en md5 ne passeront plus. Mais si on met md5, ça veut dire md5 "ou mieux", c'est-à-dire md5 ou scram-sha-256.
Donc en gros, il y a 3 options
1) si on veut se débarasser de md5 maintenant, pour augmenter la sécurité des connexions
- mettre password_encryption=scram-sha-256 et scram-sha-256 à la place de md5 dans pg_hba.conf
- recréer les mots de passe de tous les comptes (et il faut obligatoirement les connaître en clair pour faire ça)
2) si on veut une transition douce, avec un mix scram pour les nouveaux mots de passe, md5 pour les anciens
- mettre password_encryption=scram-sha-256 et laisser md5 dans pg_hba.conf
- ne pas recréer les mots de passe existants
3) si on ne veut pas de scram pour le moment
- mettre password_encryption=md5 et laisser md5 dans pg_hba.conf
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Bonjour Daniel,
Merci pour cette explicitation vraiment très claire.
Je crois que je me suis laissé abusé par le message d'erreur de mes connexions avec mon super user.
En effet dans mon cas je restaure une sauvegarde déjà hashée en md5 alors que j'ai recrée le superuser localement sur la nouvelle machine en le hashan avec shram.
Donc la connexion locale passe sans soucis (psql -U monsuperuser), alors que l'exécution du fichier contenant les comptes m'a obligé à redescendre la connexion en md5 car je fais des connexions au bases vivantes et en pg 12 pour avoir des stats sur le nombre de tables à sauvegarder et les comparer avec la restauration sachant que j'utilise une méthode de connexion distinct (tcp/ip) pour me connecter ...
Merci pour votre aide
Dernière modification par tholot (05/04/2023 09:50:14)
Hors ligne
Bonjour,
Il est quand vraiment dommage qu'il n'y ai pas la possibilité de réencoder les mots de passe en scram-sha...
Dernière modification par genamiga (08/07/2022 13:56:35)
Hors ligne
