Discussion :

[Sve@r]

Bonjour à tous

Je suis en train de développer une application IHM. A un certain moment j'offre à l'utilisateur la possibilité de changer son mot de passe de connexion à la bdd. Je lui donne donc un champ "ancien mot de passe" à saisir et deux champs "nouveau mot de passe". Ok je checke que les nouveaux mots de passe sont identiques et différents de l'ancien puis je checke que l'ancien mot de passe est bon puis je lance un alter role ... password ... pour modifier le mot de passe en bdd.

Sauf que je ne sais pas comment faire l'étape "checker ancien mot de passe". Comment vérifier que le mot de passe entré est bien celui stocké dans pg_authid? En plus c'est l'IHM qui fait le check, IHM qui possède les droits de l'utilisateur lequel n'a pas le droit de lire pg_authid. Je pourrais tenter une nouvelle connexion avec ce mot de passe et checker si la connexion est/n'est pas acceptée mais d'une part je trouve ça lourd et d'autre part mon appli pourrait bien tourner dans des environnements qui ne nécessitent pas de mot de passe pour se connecter (methode "trust" dans pg_hba.conf).

Voilà. Si quelqu'un sait comment monter cette requête...

Merci à tous.

[ced]

Bonjour,

En tentant une connexion avec le nom de l'utilisateur et son ancien mot de passe, avant la modification du mot de passe. Si la connexion fonctionne, c'est que le mot de passe est bon, sinon c'est qu'il n'est pas bon (dès lors que pg_hba.conf autorise bien la connexion de l'utilisateur en question à la base de données depuis le serveur d'application)...
Parce que pour faire autrement, ça dépend du type de stockage des mots de passes sur le serveur PostgreSQL (MD5 ou SCRAM-SHA-256). Là, il faut hasher le mot de passe selon la même méthode et comparer au hash stocké dans PostgreSQL. Plus compliqué à mettre en œuvre.

ced

[Sve@r]

En tentant une connexion avec le nom de l'utilisateur et son ancien mot de passe, avant la modification du mot de passe. Si la connexion fonctionne, c'est que le mot de passe est bon, sinon c'est qu'il n'est pas bon (dès lors que pg_hba.conf autorise bien la connexion de l'utilisateur en question à la base de données depuis le serveur d'application)...

Hé oui, c'était une idée que j'ai eue. Mais comme je l'ai dit, si mon appli est positionnée sur un serveur qui est en mode "trust" (et ça je ne maitrise pas), alors toute connexion sera acceptée même si pwd faux (j'ai déjà testé).

Là, il faut hasher le mot de passe selon la même méthode et comparer au hash stocké dans PostgreSQL. Plus compliqué à mettre en œuvre.

D'autant plus que je n'ai pas accès à pg_authid et pg_roles ne donne pas les mots de passe. Et il me semble que le hash, même s'il est md5, fait intervenir une espèce de graine permettant de rendre le hash plus ou moins aléatoire.

Pour l'instant ma solution c'est quand l'utilisateur se connecte, je stocke le mot de passe qu'il saisit dans une variable spécifique de la fenêtre qui propose le changement. Ensuite quand il veut changer, je checke si le mot de passe qu'il saisit est le même que celui qui est enregistré. C'est pas très propre (il n'y a pas d'indépendance du module qui permet de changer le mot de passe et en POO on n'aime pas trop ça) mais je ne vois pas d'autre solution.
C'est quand-même dommage qu'il n'y ait pas une requête/fonction toute faite permettant de dire "oui/non" mais je suppose que si elle existait, ce serait trop facile alors de créer des attaques brute force. Encore que ce genre d'attaque ne pourrait se faire que depuis une instance déjà connectée et la requête/fonction pourrait être verrouillée que pour l'utilisateur qui la lance ce qui limiterait le danger...

ça dépend du type de stockage des mots de passes sur le serveur PostgreSQL (MD5 ou SCRAM-SHA-256)

Ca se paramètre ça?

[ced]

Hé oui, c'était une idée que j'ai eue. Mais comme je l'ai dit, si mon appli est positionnée sur un serveur qui est en mode "trust" (et ça je ne maitrise pas), alors toute connexion sera acceptée même si pwd faux (j'ai déjà testé).

Le mode "trust", c'est mal . Il faut absolument l'éviter...
Quoi qu'il en soit, l'authentification d'une connexion est la conjonction de 3 facteurs :

1. l'adresse de l'hôte de connexion
2. la base de donnée à laquelle on se connecter
3. l'utilisateur qui se connecte

Un serveur positionné en mode "trust", ça voudrait dire alors que vous autorisez la connexion de n'importe quel utilisateur depuis ce serveur en mode "trust". Déjà que pour l'utilisateur applicatif, c'est pas bien, mais pour l'ensemble des utilisateurs, c'est encore pire et encore plus déconseillé.
Et donc, si vous mettez une vérification de mot de passe pour tout autre utilisateur que l'utilisateur applicatif (encore une fois, il faut le faire même pour l'utilisateur applicatif, et surtout pour celui-là), alors vous pouvez tester la connexion.

Pour ce qui est de la configuration du mot de passe en MD5 ou en SCRAM-SHA-256, il faut, pour le second, être au moins en version 10. Ensuite, pour tous les comptes, c'est soit l'un, soit l'autre. Mais de mémoire, on ne peut pas faire cohabiter les deux...

[Sve@r]

Un serveur positionné en mode "trust", ça voudrait dire alors que vous autorisez la connexion de n'importe quel utilisateur depuis ce serveur en mode "trust". Déjà que pour l'utilisateur applicatif, c'est pas bien, mais pour l'ensemble des utilisateurs, c'est encore pire et encore plus déconseillé.

Euh oui j'en ai bien conscience (je me suis un peu amusé avec pg_hba.conf pour regarder). Mais encore une fois, je ne suis pas maitre de l'endroit où sera installé mon appli. Moi je fournis l'appli et la bdd, c'est tout.

Je vais quand-même aller poser la question/ouvrir un ticket sur le forum de l'équipe Postgres

[Sve@r]

Bon, un mois après je reviens donner les conclusions de cette affaire.

Je suis allé sur un forum dédié à Postgres et là j'ai eu ma réponse. Et en effet il n'y a pas moyen de checker un mot de passe par rapport au mot de passe stocké dans pg_authid.
La solution qu'on m'a proposé est de créer dans ma bdd une table spécifique contenant les users et leurs mots de passe. Ce qui offre trois avantages

• je peux maintenant vérifier le mot de passe de l'utilisateur quand il veut le changer
• si en plus je rajoute des tables de gestion de droits d'accès, je peux alors supprimer les comptes de mes users dans Postgres et le remplacer par un compte dédié à l'application. C'est l'application qui se connecte à la bdd via son compte dédié puis l'user qui, en se connectant à l'application, n'aura que les droits que l'appli lui donne, droits lus dans ces tables de gestion. Et cela rend alors l'appli compatible avec un pooler de connexion (chose dont je ne m'étais pas préoccupé jusqu'alors)
• l'utilisateur n'ayant pas de compte Postgres, ne pourra pas plugguer un linux portable sur le réseau et taper un psql ... pour entrer manuellement sur la bdd (chose qu'il est possible de faire actuellement)

Bon ben voilà, pb résolu, merci à ced pour ses avis et conseils