cela veut-il dire qu'il serait possible de modifier le code pour
donner la "préséance" au md5, de telle sorte que le login se passe
bien pour tous les dbms ?
(genre on recherche le mot de passe md5, si il existe et qu'il
correspond, on se loggue, si il ne correspond pas, on met une erreur,
et si il n'existe pas, on vérifie avec la version hash de mysql. parce
que j'ai l'impression - mais j'ai pas encore regardé le code
attentivement - que pour l'instant, on essaie d'abord de se logguer
avec le hash mysql plutot que md5)
nicodache
On Apr 1, 2005 12:06 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Bonjour,
> >
> > Je viens de terminer un premier rapide petit tour du code, et voici
> > les horreurs propres à MySQL que j'ai pu trouver (ceci aidera
> > peut-être certaines personnes qui sont également en train de porter
> > GLPI vers d'autres DBMS, et indiquera aux développeurs de
> > l'application comment coder le plus standard possible avec un DBMS qui
> > en est loin ;-)) :
> >
> > - lors de l'authentification de l'utilisateur (ex : glpi), vous
> > utilisez la fonction password de mysql (SELECT password('$password')
> > AS password). Ce qui est comique la dedans, c'est qu'il m'a été
> > signalé (par guiguidoc) que cette fonction est utilisée en interne par
> > MySQL pour vérifier l'identification d'un utilisateur, et qu'elle ne
> > devait pas etre utilisée pour un projet de développement. De plus,
> > cette fonction (de hachage) n'est en rien comparable à ce qu'o peut
> > trouver dans la nature, à savoir qu'il ne s'agit pas de MD5, de SHA,
> > ou encore de DES, ce qui signifie que tant avec PHP qu'avec une base
> > de donnée, il ne sera possible de reproduire le comportement de cette
> > fonction. Il faut donc absolument se passer de cette fonction (ce qui
> > pose un autre problème; l'utilité de garder le password haché dans la
> > base de donnée, ainsi que la somme MD5 du hash. Pourquoi ne pas garder
> > simplement le MD5 du password clair ? bien que l'algorithme MD5 ait
> > été "cassé" récemment, il faut encore un pc plutot puissant pour en
> > venir à bout, ce qui fait que transférer un MD5SUM de password par le
> > réseau est probablement aussi - si pas plus sécurisé que le password
> > de mysql, celui-ci utilisant un hash de 45 bits. Faudra qu'on en
> > discute, car j'avoue que ca obligera à réécrire toute la partie
> > authentification user)
> >
>
> Si vous regardez bien l'authentification, vous vous rendrez compte
> qu'actuellement elle fonctionne en mode dégradé, c'est à dire que
> effectivement l'on utilise la fonction password de mysql et ce n'est pas
> de notre fait, c'etait comme ça historiquement au moment du fork duquel
> nous avons hérité aussi d'une bonne partie de ce que vous appelez plus
> haut les "les horreurs propres à MySQL".
> Par contre nous utilisons aussi un hash du mot de passe en md5.
>
> Tout cela date de la version 0.4 ou 0.41 dans laquelle nous avons été
> confronté au changement d'algorythme de la fonction PASSWORD de mysql dans
> leur version 4 ou 4.1.
>
> L'authentification avec password a été gardée pour préserver la
> compatibilité ascendante avec les structures utilisant GLPI en production
> depuis avant la version 0.4, si l'on avait changé totalement le systeme de
> login il nous était impossible de regénerer les mots de passe de leurs
> utilisateurs lors des mises a jour.
>
> Par contre a chaque fois qu'un utilisateur se loggue, si le champs
> password_md5 de l'enregistrement lui correspondant est vide, GLPI génére
> le md5 du mot de passe et rempli le champs.
>
> On pourra donc considèrer qu'au bout d'un certain temps tous les
> utilisateurs se seront loggué au moins une fois sur une 0.4 ou supérieure
> et donc on pourra supprimer le champs password et l'utilisation de la
> fonction password de mysql, surement pour la prochaine version dans
> laquelle nous reverrons aussi notre systeme d'update.
>
> C'est la chose la mieux qu'on a trouvé pour résoudre ce probleme à
> l'époque, si néanmoins quelqu'un a une meilleure idée... elle est la
> bienvenue.
>
> --
> Bazile
>
>
> _______________________________________________
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
>
