Question:
Sécurité https - le mot de passe doit-il être haché côté serveur ou côté client?
johndodo
2011-11-02 15:13:11 UTC
view on stackexchange narkive permalink

Je crée une application Web qui oblige les utilisateurs à se connecter. Toutes les communications passent par https. J'utilise bcrypt pour hacher les mots de passe.

Je suis confronté à un dilemme - je pensais qu'il était plus sûr de faire un hachage de mot de passe côté client (en utilisant JavaScript) et de le comparer ensuite avec le hachage dans DB du côté serveur. Mais je ne suis pas sûr que ce soit mieux que d'envoyer un mot de passe en texte brut sur https, puis de le hacher côté serveur.

Mon raisonnement est que si un attaquant peut intercepter le trafic https (= lire le mot de passe en texte clair), il peut par exemple également changer le JavaScript afin qu'il envoie le mot de passe en clair à côté du mot de passe haché - où il peut l'intercepter.

La raison contre le hachage côté client est simplement la facilité d'utilisation. Si je hache côté client, je dois utiliser deux bibliothèques distinctes pour le hachage. Ce n'est pas un problème insurmontable, mais c'est une nuisance.

Y a-t-il un gain de sécurité à utiliser le hachage côté client? Pourquoi?

Dois-je également utiliser la réponse par défi?

MISE À JOUR: ce qui m'intéresse le plus, c'est ceci - faire ces techniques (côté client hashing, request-response) ajouter un gain de sécurité significatif dans le cas où https est utilisé? Si oui, pourquoi?

http://stackoverflow.com/questions/3715920/about-password-hashing-system-on-client-side
Merci pour le lien, mais bien que la situation soit similaire, il y a une différence subtile - j'utilise https. Aussi, je trouve que l'explication des réponses manque ... Si la page peut être lue, elle peut également être modifiée, ce qui signifie que l'utilisateur entrera son mot de passe sous une forme qui a été fournie par l'attaquant. Je mettrai à jour la question pour mieux le souligner.
Voir également http://security.stackexchange.com/q/23006/2379
Personnellement, je pense que tous les clients devraient saler et hacher leurs mots de passe avant de les envoyer.Je ne vois aucune raison pour laquelle je donnerais mon mot de passe en clair à un serveur, alors qu'une version hachée fonctionnerait tout aussi bien.Je suis déçu que ce ne soit pas une pratique courante.(Et oui, bien sûr, les mots de passe doivent également être salés et hachés sur le serveur.)
Suite à ma diatribe, voici quelqu'un qui pose quelque chose de similaire à une question: [Comment s'authentifier sur un site Web avec des clés publiques / privées?] (Http://security.stackexchange.com/questions/100266/how-to-authenticate-in-un-site-avec-clés-publiques-privées)
@joeytwiddle Cela ne fonctionne que si le serveur fournit le sel (défi-réponse).Étant donné deux mots de passe hachés avec des valeurs de sel différentes, il n'est pas possible de dire si le mot de passe d'origine était le même.
Hash (au moins) une fois sur le client et une fois sur le serveur et avec différents, fournis par le serveur pour chaque utilisateur.De cette façon, vous protégez également les utilisateurs qui utilisent "baseball" pour chaque mot de passe.
Dix réponses:
#1
+130
Nicole Calinoiu
2011-11-02 17:11:19 UTC
view on stackexchange narkive permalink

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).

Pouvez-vous expliquer pourquoi vous pensez qu'il en est ainsi? AFAIK le seul avantage à utiliser des mots de passe hachés est de protéger les comptes des utilisateurs sur ** d'autres ** sites Web en cas de vol des mots de passe / mots de passe hachés - rien d'autre. Si tel est le cas, il ne devrait y avoir aucune différence là où le hachage est effectué. Y a-t-il un autre avantage du hachage que j'ai manqué?
Le stockage d'un hachage salé est en fait censé aider à protéger votre application contre un attaquant obtenant des informations d'identification en lisant le contenu du magasin de données d'authentification. S'il ne peut pas déduire un mot de passe du magasin, il ne peut pas le transmettre au serveur pour l'authentification.
Aaaah, cela a du sens ... L'attaquant s'empare du mot de passe haché, mais il ne peut pas l'utiliser sur ce système car le système le hache tout seul - il devrait donc d'abord trouver le mot de passe d'origine. Joli! :)
Oui, le hachage du mot de passe devient le jeton d'authentification - mais si cela peut être intercepté, l'identifiant de session le peut aussi. Bien que ce dernier ne permette que d'abuser de la session, tandis que le premier permet à l'attaquant d'ouvrir de nouvelles sessions, l'avantage proposé n'est pas vraiment si grand et repose sur une attaque MITM sur la connexion SSL.
@johndodo "_le seul avantage à utiliser des mots de passe hachés est de protéger les comptes des utilisateurs sur d'autres sites Web au cas où les mots de passe / mots de passe hachés seraient volés_" Pas seulement une raison. Mais encore, c'est une raison.
Cette réponse n'est pas vraiment juste.Il met en évidence la vulnérabilité d'une approche * naïve * du hachage côté client.Il est certainement vrai que si le serveur ne fait aucun hachage et ne stocke que la valeur que le client envoie, ce ne serait pas mieux que de stocker des mots de passe en clair.Mais la solution simple est de hacher * à la fois * le client et le serveur.Et avec cette solution simple en place, nous gagnons un avantage significatif: le coût du hachage de mot de passe gourmand en ressources peut être déplacé du serveur vers le client, et probablement augmenté au-delà de ce que le serveur pourrait prendre en charge.
@LuisCasilla Non.La première phrase de la réponse s'applique toujours - le hachage du mot de passe côté client n'ajoute aucune sécurité supplémentaire au système.
De plus, il est préférable de contrôler toutes les authentifications côté serveur, car il est évidemment plus facile de pirater un client.
Votre première phrase et vos conclusions générales sont correctes mais vos deux dernières phrases sont complètement fausses.Le hachage côté serveur est définitivement la voie à suivre, et le hachage côté client fait en effet du hachage le mot de passe.Cependant, si je devais choisir entre un système qui stocke les mots de passe en texte brut ou le hachage côté client, je prendrais le hachage côté client à chaque fois.Le hachage côté client protège au moins toujours le mot de passe réel, qui est le point entier du hachage - pour protéger l'utilisateur de sa propre réutilisation de mot de passe.
Je pense que c'est pourquoi votre dernière phrase me dérange tellement.Le but du hachage n'est pas de hacher pour des raisons de hachage - c'est de faire en sorte que si un attaquant trouve vos bases de données de mots de passe, il ne puisse pas comprendre quels étaient les mots de passe d'origine, car ils iraient tous s'infiltrer.les autres comptes avec lesquels l'utilisateur a utilisé ce mot de passe.Avec le hachage côté client, la protection est toujours en place et suggérer que le hachage côté client est aussi mauvais que les mots de passe en texte brut est tout simplement faux.Je pense que vous avez perdu la forêt pour les arbres.
@ConorMancone: Je soupçonne que vous inférez quelque chose de ma réponse qui n'a jamais été voulu.Cette question concerne le hachage sur le client par rapport au serveur, et non le hachage.La réponse indique que le stockage des mots de passe en texte brut est une mauvaise idée, mais cela a été mentionné comme un aparté puisque j'avais supposé au moment de la rédaction de la réponse que l'OP comprenait la raison principale du hachage.(En outre, il convient de noter que la protection de l'utilisateur dans les scénarios de réutilisation de mot de passe n'est _pas_ la principale raison du hachage de mot de passe.)
@NicoleCalinoiu votre dernière phrase indique clairement que le hachage côté client est aussi peu sûr que l'utilisation de mots de passe en texte brut.Ce n'est pas vrai et c'est une équivoque dangereuse.Bien que pire que le hachage côté serveur, le hachage côté client empêche toujours le mot de passe d'origine d'être récupéré et utilisé pour tenter de s'introduire dans d'autres services, ce qui est une faiblesse critique contre laquelle il faut se protéger.Par conséquent, le hachage côté client est bien meilleur que la simple transmission / stockage de mots de passe en texte brut, et je pense qu'il est beaucoup plus sûr de ne pas laisser entendre le contraire.
@NicoleCalinoiu RE: l'utilisation principale du hachage: je ne suis pas du tout d'accord.La protection de l'utilisateur dans les scénarios de réutilisation de mot de passe * est * la principale raison du hachage de mot de passe.Contrairement à votre commentaire en haut de ce fil, le hachage ne fournit qu'une faible protection contre les attaquants qui accèdent au compte s'ils obtiennent un accès en lecture à une base de données (par exemple).Les systèmes peuvent également stocker les données de session dans des bases de données, ce qui donne accès aux comptes même si les mots de passe sont hachés.De plus, le chiffrement pourrait être tout aussi efficace que le hachage dans ce scénario.Nous hachons pour nous protéger contre la réutilisation des mots de passe.
Aucun de vous n'a dit l'autre chose.le hachage côté client rend le mot de passe MOINS SÉCURISÉ pour les mots de passe forts.c'est-à-dire que si j'avais un mot de passe généré utilisant tous les jeux de caractères (haut / bas / num / symboles) de longueur longue mais aléatoire, et que vous le hachiez, par définition du hachage, vous avez introduit que différents mots de passe (collisions) peuvent également fonctionner, et l'attaquanta moins de «mots de passe possibles» à la force brute.
#2
+33
Thomas Pornin
2012-10-28 00:56:52 UTC
view on stackexchange narkive permalink

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).

#3
+11
rmorero
2011-11-02 15:25:28 UTC
view on stackexchange narkive permalink

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?

"_Si votre logique de hachage est côté client, vous l'exposez._" Et alors?
Peut-être pas un gros problème. Mais je préfère exposer le moins possible. Disons que vous vous procurez une base de données avec des mots de passe hachés. Si vous connaissez l'algorithme de hachage, vous pouvez générer une liste de hachages à partir d'une liste de mots de passe courants et les faire correspondre.
@rmorero: J'ai tendance à ne pas être d'accord ... Tout d'abord, vous ne pouvez pas faire grand-chose pour éviter que l'utilisateur laisse le terminal déverrouillé, à part [sonar] (http://stevetarzia.com/sonar/) et autres. En outre, masquer l'algorithme de hachage est la sécurité par l'obscurité. Vous devez décider de ce qui est secret et de ce qui ne l'est pas. Cacher des choses non secrètes est généralement contre-productif.
@johndodo C'est vrai, ce sont des points valides. Et ma logique ci-dessus dépend en partie d'une mauvaise implémentation. Pourtant, je dirais que la sécurité par l'obscurité n'est contre-productive que si vous vous y fiez; ce que je ne recommande pas.
@rmorero: le danger en sécurité par l'obscurité n'est pas tant que de s'y fier ... Comme je le vois, les trois problèmes majeurs sont: a) vous passez votre temps dessus plutôt que sur de vraies solutions, b) vous pourriez faire une erreur et en fait aggraver la sécurité, et c) cela rend le système moins transparent et pourrait ainsi cacher d'autres erreurs. En d'autres termes, cela ajoute du «brouillard» - et comme un hacker expérimenté a probablement des antibrouillards dans son arsenal, je préférerais une journée ensoleillée pour lui faire face. ;)
@johndodo Je suis en partie d'accord avec vous. Pour a) Dans certains cas, c'est vrai, mais si la mise en œuvre est la même pour une solution publique et une solution cachée? Pour b) Vrai. Mais vous pourriez aussi faire la même erreur dans votre implémentation publique - ce serait juste plus rapide à détecter? c) Certes, je suis également favorable à la transparence; mais par cette même logique recommanderiez-vous également d'exécuter tout dans un système sur des ports standard?
@rmorero "_par cette même logique recommanderiez-vous également d'exécuter tout dans un système sur des ports standard? _" Ne pas obscurcir les choses ne signifie ** pas ** que vous devez utiliser des ports standard. L'utilisation de ports non standard n'est pas qu'une simple obscurité.
#4
+10
Samuel
2015-09-18 02:01:03 UTC
view on stackexchange narkive permalink

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.

Je n'envisagerais pas d'activer / de faciliter la réutilisation des mots de passe comme un avantage.Et le mot de passe en texte brut n'est jamais envoyé sur le fil en raison de l'utilisation de HTTPS.
@augurar Je n'appellerais pas cela activer ou faciliter la réutilisation des mots de passe.Les utilisateurs sont des humains et les humains font des choses non recommandées comme la réutilisation des mots de passe.Je considère que cela va dans le même sens que d'empêcher l'utilisateur de choisir un mot de passe faible.Le hachage du mot de passe côté client compense le fait que beaucoup de vos utilisateurs utiliseront le même mot de passe sur votre site que leurs banques.En ce qui concerne votre deuxième déclaration, si le serveur est compromis, ils peuvent voir la requête HTTP déchiffrée et le mot de passe en texte brut.
+1 par seconde, le hachage côté client est le seul moyen de prouver que vous ne cultivez pas les mots de passe.https://xkcd.com/792/
#5
+2
bua
2011-11-02 15:19:43 UTC
view on stackexchange narkive permalink

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.

Il convient de noter que les sels fixes + challenge avec hachage côté client peuvent être utilisés pour implémenter un mécanisme de mot de passe sécurisé sur des connexions non cryptées (mais évidemment, le jeton de session et les autres échanges ultérieurs ne sont pas sécurisés)
@symcbean Qu'entendez-vous par «sécurisé»?
Je veux dire que le mécanisme de transmission des mots de passe n'est pas soumis à l'écoute clandestine.
bua, merci En se rapprochant, mais il n'y a pas d'états de session, j'utilise flex
@kwolbert vous continuez à publier des commentaires comme de nouvelles réponses au lieu de commentaires. Pourriez-vous s'il vous plaît joindre ceci comme un commentaire où vous voulez qu'il soit lu dans le contexte, puis supprimer la réponse ici? Merci.
@kwolbert Bienvenue dans la sécurité informatique! Veuillez utiliser le bouton * Publier la réponse * uniquement pour les réponses réelles. Vous devez modifier votre question d'origine pour ajouter des informations supplémentaires.
#6
+1
Anonymous
2017-01-21 01:47:38 UTC
view on stackexchange narkive permalink

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).

"* Vous devez gérer ce scénario *" ... si vous souhaitez conserver ces utilisateurs.C'est 1% des gens et je pense que 90% d'entre eux peuvent être convaincus de l'activer si votre site Web n'est pas plein de conneries.
#7
+1
Ini
2017-08-15 04:04:31 UTC
view on stackexchange narkive permalink

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.

#8
+1
nat that
2020-01-14 01:47:01 UTC
view on stackexchange narkive permalink

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.

#9
-1
codetaku
2017-01-20 21:13:19 UTC
view on stackexchange narkive permalink

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.

Si vous ne faites pas confiance à vos administrateurs, vous êtes dans un monde beaucoup plus blessé que de devoir vous soucier qu'ils volent occasionnellement un mot de passe utilisateur dans la RAM.Si vous avez un administrateur de serveur malveillant, vous ne pouvez plus protéger les mots de passe des utilisateurs, notamment en essayant de les hacher côté client, au moins pour une application Web.
Eh bien, qu'en est-il de ce problème de cloudflare qui vient de surgir?Je dis toujours que le hachage aux deux extrémités est le seul moyen sûr de le faire.De plus, si vous pensez que la modification de la sortie (l'étape nécessaire pour faire échouer «essayer de hacher côté client») est aussi simple que de jeter un coup d'œil à l'entrée, vous n'avez jamais vu d'ordinateur physique.
#10
-6
user3738142
2016-04-07 23:49:20 UTC
view on stackexchange narkive permalink

À 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.

Ce n'est pas parce qu'un mot de passe est envoyé en texte brut qu'il est stocké en texte brut.Si un attaquant a compromis le serveur au point de pouvoir voir le trafic entrant, il peut probablement modifier le code envoyé au client pour récupérer également le mot de passe de l'utilisateur.
Si le serveur est jamais compromis, le code que le serveur envoie au client le sera aussi, pour effectuer le hachage côté client, il s'agit donc effectivement d'un contrôle inutile contre un serveur malveillant.
@Matthew C'est cependant visible pour l'utilisateur.La capture côté serveur ne l'est pas.(Cela vaut aussi pour Xander mais je ne peux pas cingler deux en même temps.) Si une banque assez grande fait du hachage côté client, je ne serais pas surpris si les gens commencent à surveiller les fichiers javascript (peut-être la banque elle-même à partir d'un externeIP) ou si des modules complémentaires apparaissent qui vérifient les changements depuis la dernière visite.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...