Si vous effectuez un hachage côté client, le mot de passe haché devient le mot de passe réel (l'algorithme de hachage n'étant rien de plus qu'un moyen de convertir un mnémonique détenu par l'utilisateur en mot de passe réel).

Cela signifie que vous stockerez le mot de passe "plain-text" complet (le hachage) dans la base de données, et vous aurez perdu tout avantage du hachage en premier lieu.

Si vous décidez d'emprunter cette voie, vous pouvez tout aussi bien renoncer à tout hachage et simplement transmettre et stocker le mot de passe brut de l'utilisateur (ce que, d'ailleurs, je ne recommanderais pas particulièrement).

Le hachage sur le client n'a de sens que si vous ne faites pas confiance au serveur d'une manière ou d'une autre, et ne voulez pas lui montrer le mot de passe "réel" (celui dont l'utilisateur se souvient). Pourquoi ne voudriez-vous pas montrer le mot de passe au site même sur lequel ledit mot de passe a une quelconque utilité? Parce que vous avez réutilisé le mot de passe ailleurs! Maintenant, c'est généralement mauvais, mais il existe une version relativement sûre qui est incarnée dans une myriade d'extensions de navigateur ou de signets tels que celui-ci ou celui-là (je ne garantis pas leur qualité). Ce sont des outils où l'utilisateur humain se souvient d'un "mot de passe principal", à partir duquel un mot de passe spécifique au site est généré, en utilisant le nom de domaine du site comme une sorte de sel, de sorte que deux sites distincts obtiennent des mots de passe distincts.

Bien que ce scénario ait du sens, le faire avec Javascript envoyé par le serveur lui-même ne l'est pas. En effet, le point de hachage du mot de passe côté client est que le serveur est potentiellement hostile (par exemple subverti par un attaquant), et donc le code Javascript envoyé par ce serveur est, à tout le moins, suspect. Vous ne voulez pas entrer votre précieux mot de passe dans un Javascript hostile ...

Un autre cas de hachage côté client concerne le hachage lent . Les mots de passe étant, par définition, faibles, vous souhaitez contrecarrer les attaques par dictionnaire. Vous supposez que le méchant a obtenu une copie de la base de données du serveur et qu'il "essaiera des mots de passe" sur ses propres machines (voir ce billet de blog pour une discussion à ce sujet). Pour ralentir l'adversaire, vous utilisez un processus de hachage intrinsèquement lent (tel que bcrypt), mais cela ralentira le traitement pour tout le monde, y compris le serveur. Pour aider le serveur, vous voudrez peut-être décharger une partie du travail sur le client, donc faites-en au moins une partie dans du code Javascript exécuté dans le navigateur client ...

Malheureusement, Javascript est terriblement lent pour ce genre de travail (généralement 20 à 100 fois plus lent que le code C décent), et le système client ne pourra pas contribuer pour une part substantielle à l'effort de hachage. L'idée est bonne mais devra attendre une meilleure technologie (cela aurait cependant fonctionné avec un client Java : avec une JVM décente, le code Java optimisé est environ 2 à 4 fois plus lent que le code C optimisé , pour un travail de hachage).

Pour résumer, il n'y a pas vraiment de bonnes raisons de faire un hachage de mot de passe côté client, à partir du code Javascript envoyé par le serveur lui-même. Envoyez simplement le mot de passe "tel quel" au serveur via un tunnel HTTPS (la page de connexion, l'URL de destination du formulaire et toute page protégée par le mot de passe doivent tous être servis via SSL, sinon vous ont des problèmes de sécurité plus urgents que l'utilisation de mots de passe).

Je trouve que toutes vos préoccupations sont valables, mais ma recommandation serait de le faire côté serveur.

Il y a toujours une assez grande chance qu'un utilisateur laisse son terminal déverrouillé, permettant la manipulation. Et aussi; si votre logique de hachage est côté client, vous l'exposez.

Une autre option serait de générer les mots de passe côté serveur; alors vous n'envoyez pas de mot de passe en texte clair. Mais vous devrez toujours communiquer le mot de passe à l'utilisateur. Et comme la plupart des utilisateurs n'utilisent toujours pas de courrier électronique crypté, je considère que cela est moins sûr.

J'ai vu des solutions pour envoyer des mots de passe via un tunnel crypté vers un téléphone portable; mais je doute que la sécurité soit meilleure que le SSL. Peut-être que quelqu'un pourrait prouver / réfuter cela?

Le hachage côté serveur est important comme toutes les autres réponses l'ont indiqué, mais je voudrais ajouter que le hachage côté client serait une fonctionnalité de sécurité intéressante en plus du hachage côté serveur.

Le hachage côté client présente des avantages dans les scénarios suivants:

1. Protège le mot de passe de l'utilisateur lorsque le serveur est compromis. C'est à dire. si le client n'est pas compromis, mais que le serveur l'est, si le client hache le mot de passe, le serveur pourrait toujours accéder à l'unique système, mais vous avez protégé le mot de passe de l'utilisateur, ce qui est important s'il utilise ce mot de passe ailleurs.
2. Protège le mot de passe de l'utilisateur lorsque l'utilisateur pense se connecter à un serveur mais qu'il se connecte vraiment à un autre (erreur de l'utilisateur). Par exemple, si j'ai deux comptes bancaires et que je tape accidentellement l'un des mots de passe de ma banque sur le mauvais site Web de la banque, si la banque a haché le mot de passe côté client, cette banque ne connaîtrait pas le mot de passe de mon autre banque. Je pense que ce serait une chose "polie" à faire pour hacher côté client afin que leur mot de passe en texte brut ne soit jamais transmis sur le fil.

Surtout, cela montre le respect du mot de passe de l'utilisateur. L'utilisateur partage un secret qui n'est peut-être pas exclusif à votre logiciel, donc si vous respectez ce secret, vous devez faire tout ce qui est en votre pouvoir pour le protéger.

Si vous êtes dans un tunnel HTTPS, le mot de passe ou le hachage doit être sécurisé de la surveillance Ethernet.

Du côté client, vous pourriez peut-être saler le hachage avec un identifiant de session.
Cela pourrait être plus difficile pour le Javascript malveillant à simuler.

Le hachage du mot de passe côté client nécessitera Javascript. Certaines personnes désactivent Javascript sur leur navigateur. Vous devez gérer ce scénario.

J'ai vu un logiciel de forum qui effectue le hachage du mot de passe côté client et envoie le hachage lors de la connexion si possible , sinon le mot de passe est envoyé en clair texte. Cela fonctionne donc dans les deux cas.

L'envoi du mot de passe en clair n'est pas un problème majeur si vous utilisez https. Idéalement, votre serveur devrait alors refuser de servir des pages en http afin d'éviter une attaque de type man in the middle. Le raisonnement étant le suivant: un attaquant pourrait de force «rétrograder» votre connexion de https à http et commencer à renifler le trafic (par exemple avec un outil comme SSL Strip).

La réponse acceptée de @Nicole Calinoiu est bien sûr correcte mais peut-être trop difficile à comprendre au début.

Le point est le mot de passe doit être haché sur le serveur afin que la personne malveillante ne puisse pas utiliser les hachages qu'il a piratés à partir de la base de données du serveur pour accéder à votre compte ou à vos données.

Comme déjà dit, si vous hachez côté client et que le back-end le prend en charge, alors le hachage devient votre mot de passe et si le hachage est volé via un hack, alors le hacker a le mot de passe. p La réponse>

@Thomas Pornin a également proposé un très bon point pour lequel vous voudriez hacher le mot de passe sur le client, mais la chose qu'il décrit dans sa première histoire ne peut être faite que si le back-end du serveur prend en charge la gestion des mots de passe hachés (c'est-à-dire ne pas hacher le mot de passe s'il est déjà haché, mais que quelqu'un essaie de prendre en charge quelque chose comme ça est très peu probable), ce qui sera la plupart des le temps ne soit pas le cas, je suppose. La deuxième histoire de lui est très bonne.

Vous pouvez faire les deux, vous le hachez au niveau du client, donc si l'attaquant peut passer par la sécurité https, il ne pourra pas voir le mot de passe en texte brut. Ensuite, hachez-le à nouveau sur le serveur afin que si l'attaquant récupère les mots de passe stockés sur le serveur, il ne peut pas simplement les envoyer au serveur et accéder au mot de passe.

Si votre serveur doit avoir plusieurs administrateurs possibles et que vous ne pouvez pas nécessairement tous leur faire confiance pour ne pas obtenir de vidage mémoire, vous devez vraiment hacher le côté client pour empêcher les administrateurs de voler les mots de passe des utilisateurs [qui peuvent être réutilisés sur d'autres sites Web- -malgré cela étant une mauvaise pratique, les utilisateurs le font et continueront de le faire], puis hacher ce côté serveur de hachage afin que le vol de la table ne donne pas automatiquement aux attaquants le mot de passe en clair le site Web lui-même.

Et tant que vous utilisez la fonction de hachage sécurisé, vous pouvez utiliser le même sel pour les deux côtés.

À toutes fins utiles, vous ne voudrez hacher que du côté client. L'idée derrière un hachage est d'empêcher quiconque, sauf l'utilisateur, de connaître le mot de passe. Comme tout bon site devrait utiliser TLS, le fait que le hachage soit envoyé au serveur n'a pas d'importance (notez que même si c'était un problème, l'envoi du mot de passe en texte brut serait tout aussi mauvais).

Enfin, les réponses énumérées semblent ne pas se rendre compte que si le serveur est un jour compromis, chaque mot de passe du serveur sera compromis puisque les mots de passe lui sont envoyés en texte brut.