dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Encryption de mots de passe et rappel par e-mail


From: zcp
Subject: Re: [Dolibarr-dev] Encryption de mots de passe et rappel par e-mail
Date: Mon, 12 Feb 2007 19:54:41 +0100
User-agent: IceDove 1.5.0.9 (X11/20061220)

Yannick Warnier a écrit :
Le lundi 12 février 2007 à 18:49 +0100, zcp a écrit :
[...][...]
Bonsoir

Personnellement, j'aime bien la méthode employée par Spip.
[...][...]
Je ne vois pas bien ce que tu veux dire par ticket unique (qui m'a fort
l'air d'être un simple identifiant de session), ni par premier hachage
MD5 et hachage MD5 par le serveur, mais je comprends ce que tu décris
comme le système qu'on a actuellement dans Dolibarr. L'ajout de
l'encryption au niveau de la base de données se fait uniquement pour
éviter le vol (volontaire ou involontaire) de mots de passe par des
utilisateurs qui n'ont pas "besoin" de les voir.

Yannick


Bonsoir

Concernant l'objectif du cryptage du mot de passe, nous sommes tous d'accord.

Spip gère le cas où un utilisateur n'a pas de javascript activé, il est informé 
et, son mot de passe transit en clair.

Si l'utilisateur à le javascript disponible, le mot de passe est concaténé avec 
une clef aléatoire envoyée au moment du login (oula, je dis peut être une 
bétise) et peut être encore autre chose, puis, le tout est haché en MD5 par le 
javascript avant d'être envoyé sur le serveur, rendant plus difficile le vol de 
d'identité.

Le serveur, recevant cela, effectue de nouveau un hachage MD 5, mais je ne sais 
plus avec quoi, et si je l'écris, ce serait incohérant.

En tout cas, il y a un double hachage MD5, en particulier parce que s'il n'y a 
pas de javascript chez l'internaute, il faut bien comparer le mot de passe avec 
un truc crypté dans le base de donnée.

En gros, c'est ça le principe, mais cela fait longtemps que je l'ai lu, et j'ai 
oublié les détails.

De plus, deux utilisateurs avec le même login et le même mot de passe n'auront 
pas le même résultat de hashage de mot de passe dans la base, grâce à une 
donnée aléatoire et une seconde qui est variable (peut-être l'ID de session???).

Cela ne fait que rendre plus difficile l'usurpation d'identité.

A bientôt
Grégoire




reply via email to

[Prev in Thread] Current Thread [Next in Thread]