Sauf erreur le principe c'est d'envoyer une chaine aléatoire et de dire "mixe ton mot de passe avec cette chaine et envoie moi le md5".
Pour vérifier le mot de passe il te faut :
- soit les md5 possibles pour toutes les chaines aléatoires que tu es succeptible d'envoyer (impossible si tu ne fais pas du réel aléatoire, et si tu n'as qu'un jeu réduit de chaines soit-disant aléatoire alors tu met en défaite tout le principe) pour vérifier si ça correspond
- soit le mot de passe initial (en clair) et la chaine aléatoire (tu l'as parce que c'est toi qui la fourni) pour refaire le même calcul que le client et vérifier le résultat
Vu que la première solution est impossible, il te faut bien le mot de passe en clair.
> l'applicatif peut très bien stocker sa correspondance MD5 plutôt que
> sa valeur et tester la valeur MD5 du mot de passe envoyé
Si l'applicatif envoie du md5, si toi tu n'as que du md5 pour vérifier, ça sert à quoi d'avoir crypter le mot de passe ? celui qui lit ta base (donc relit le md5) pourra te le réenvoyer pour se faire authentifier. Dans ce cas là conceptuellement le md5 devient ton mot de passe réel (en clair) et le mot de passe que l'utilisateur tape n'est qu'un raccourci facilement retenable qu'il utilise en interne de son coté. Tu ne gagnes aucune sécurité.
Le cryptage dans la base n'a aucun intérêt si ce que tu demandes au client est aussi la version cryptée. Ca ne peut avoir un intérêt que si l'un a le mot de passe en clair et l'autre le mot de passe crypté (si c'est le client qui transmet du crypté c'est pour protéger la connexion, si c'est le serveur qui stocke du crypté c'est pour protéger le stockage).
[^] # Re: Cluster?
Posté par Éric (site web personnel) . En réponse à la dépêche ejabberd 1.0.0 : le serveur Jabber qui monte (...en charge). Évalué à 2.
Pour vérifier le mot de passe il te faut :
- soit les md5 possibles pour toutes les chaines aléatoires que tu es succeptible d'envoyer (impossible si tu ne fais pas du réel aléatoire, et si tu n'as qu'un jeu réduit de chaines soit-disant aléatoire alors tu met en défaite tout le principe) pour vérifier si ça correspond
- soit le mot de passe initial (en clair) et la chaine aléatoire (tu l'as parce que c'est toi qui la fourni) pour refaire le même calcul que le client et vérifier le résultat
Vu que la première solution est impossible, il te faut bien le mot de passe en clair.
> l'applicatif peut très bien stocker sa correspondance MD5 plutôt que
> sa valeur et tester la valeur MD5 du mot de passe envoyé
Si l'applicatif envoie du md5, si toi tu n'as que du md5 pour vérifier, ça sert à quoi d'avoir crypter le mot de passe ? celui qui lit ta base (donc relit le md5) pourra te le réenvoyer pour se faire authentifier. Dans ce cas là conceptuellement le md5 devient ton mot de passe réel (en clair) et le mot de passe que l'utilisateur tape n'est qu'un raccourci facilement retenable qu'il utilise en interne de son coté. Tu ne gagnes aucune sécurité.
Le cryptage dans la base n'a aucun intérêt si ce que tu demandes au client est aussi la version cryptée. Ca ne peut avoir un intérêt que si l'un a le mot de passe en clair et l'autre le mot de passe crypté (si c'est le client qui transmet du crypté c'est pour protéger la connexion, si c'est le serveur qui stocke du crypté c'est pour protéger le stockage).