Vaut-il la peine de hacher les mots de passe côté client

Lorsque je veux mettre en place un système de connexion, je compare toujours le MD5 du mot de passe donné avec sa valeur dans la table des utilisateurs côté serveur.

Cependant, un de mes amis m'a dit qu'un mot de passe "clair" pouvait être reniflé par un logiciel réseau.

Ma question est donc la suivante : est-ce une bonne idée de hacher le mot de passe côté client ? Est-ce mieux que de le hacher côté serveur ?

Solution du problème

En fait, je ne suis pas d'accord pour dire que le hachage côté client est plus sécurisé dans ce cas. Je pense que c'est moins sûr.

Tout l'intérêt de stocker un hachage du mot de passe dans votre base de données par opposition au vrai mot de passe (ou même un mot de passe crypté) est qu'il est mathématiquement impossible d'obtenir le mot de passe d'origine à partir d'un hachage (bien qu'il soit théoriquement possible d'obtenir un mot de passe en collision entrée de hachage, dont la difficulté dépend de la force de sécurité de l'algorithme de hachage). Le vecteur d'attaque possible ici est que si un attaquant potentiel compromettait d'une manière ou d'une autre votre base de données de stockage de mots de passe, il ne serait toujours pas en mesure d'obtenir les mots de passe originaux de vos utilisateurs.

Si votre mécanisme d'authentification envoie un hachage du mot de passe, alors dans ce scénario de faille de sécurité, l'attaquant n'a pas besoin de connaître le vrai mot de passe - il envoie simplement le hachage qu'il a et hop, il a accès au compte d'un utilisateur particulier, et par extension, tout votre système. Cela va complètement à l'encontre de l'intérêt de stocker un mot de passe haché en premier lieu !

Le moyen vraiment sécurisé de le faire est d'envoyer au client une clé publique à usage unique pour qu'il chiffre le mot de passe, puis de le déchiffrer et de le re-hacher côté serveur.

Soit dit en passant, ce genre de question obtiendra probablement plus de réponses d'experts sur Security StackExchange.