Bonjour,
Je ne comprends pas trop pourquoi il faut saisir un mot de passe (un login, à la limite) dans un adhérent ? D’autant plus que ce champ est en clair dans la base de données !
Il me semblerait plus judicieux de générer un mot de passe aléatoire lors de la création de l’utilisateur, non ?
Bonjour
La gestion des mots de passes en clair est une option :
Configuration / Sécurité / Mots de passe / paramètres
Cordialement
Je suis désolé mais l’option Ne pas stocker de mots de passe en clair dans la base est bien activée. Les mots de passe dans la table llx_adherent sont bien en clairs.
En revanche, dans la table llx_user, ils sont bien cryptés. Mais vu que (sauf erreur de ma part) Dolibarr semble synchroniser le mot de passe de l’adhérent avec celui de l’utilisateur, c’est raté.
Bonjour,
Je fais remonter ce post car je me retrouve confronté au même problème:
Nous souhaitons utiliser Dolibarr couplé avec LDAP pour la gestion de notre association. Le fait que les mots de passe soient stockés en clair dans la base est vraiment bloquant.
De plus quand on crée un adhérent, il s’inscrit bien dans l’annuaire LDAP mais le mot de passe est là aussi stocké en clair.
Si quelqu’un à une piste je suis prêt à passer un peu de temps pour résoudre ce problème afin que nous puissions utiliser cette solution, merci.
Bonjour , je viens de voir passer une pull request sur github donc solution bientôt intégrée 
Merci Eldy !
Bonjour,
Non c’est moi 
https://github.com/Dolibarr/dolibarr/pull/2892
Par contre, j’ai fermé ma pull request pour l’instant car les adhérents ne pouvaient plus se connecter pour l’instant.
Je cherche le bug et je relance ma pull request.
À mon avis, conserver le champ « mot de passe » dans la table adhérent ne présente aucun intérêt. Les utilisateurs Dolibarr se connectant avec le module « utilisateurs », c’est redondant. Sans compter que lorsque l’on met un à jour la fiche adhérent, le mot de passe adhérent écrase le mot de passe utilisateur…
Cf. Doliforge #1903 et #1629.
Bonjour,
Je viens de découvrir moi aussi que les mots de passe des adhérents sont stockés en clair dans la base de données, bien que j’ai activé l’option « Ne pas stocker de mots de passe en clair dans la base », je pense que c’est un bug.
Je ne vois pas non plus l’intérêt d’avoir un mot de passe pour les adhérents mais certains peuvent utiliser cette fonction pour gérer des mots de passe pour leurs adhérents, sans pour autant que ces adhérents aient un compte utilisateur. Je trouve ça un peu tiré par les cheveux mais pourquoi pas.
De mon côté j’ai besoin de gérer un identifiant mais pas un mot de passe, je propose donc d’ajouter une option « Gérer un mot de passe pour les adhérents : Oui / Non ». Cette option ne serait visible que si « Gérer un identifiant pour chaque adhérent » est activé.
J’ai écrit à propos de tout ça sur la liste des développeurs avant de trouver cette discussion sur le forum. Je posterai un message ici s’il y a des nouvelles sur la liste ou dans le code.
La prochaine version 4.0 corrigera cela (je viens de faire un PR en ce sens)
Tout sera cryptée et uniquement crypté par défaut, aussi bien pour les user que pour les adhérents.
Le besoin d’avoir son propre champ dans la table des adhérents, vient de besoin pour la synchro LDAP. Il est entièrement synchro avec le mot de passe des users. Il faut donc le voir comme une duplication d’info sur le user.
