Pourquoi presque aucun site Web ne hache les mots de passe du client avant de les soumettre (et de les hacher à nouveau sur le serveur), afin de «protéger» contre la réutilisation des mots de passe?

46

Il existe de nombreux sites sur Internet qui nécessitent des informations de connexion, et le seul moyen de se protéger contre la réutilisation des mots de passe est la "promesse" que les mots de passe sont hachés sur le serveur, ce qui n'est pas toujours vrai.

Je me demande donc à quel point il est difficile de créer une page Web qui hache les mots de passe sur l'ordinateur client (avec Javascript), avant de les envoyer au serveur, où ils seraient hachés de nouveau. En théorie, cela n'apporte aucune sécurité supplémentaire, mais dans la pratique, cela peut être utilisé pour se protéger contre les "sites non autorisés" qui n'empiètent pas votre mot de passe sur le serveur.

— Martín Fixman
source

18

un mot de passe haché envoyé en clair est pas mieux qu'un mot de passe envoyé en clair si le serveur est simplement comparer hash, l' homme dans les attaques du milieu aiment ce genre de « sécurité »

3

La meilleure solution est (imo) un gestionnaire de mots de passe côté client. De cette façon, vous pouvez générer une chaîne de caractères aléatoire comme mot de passe et vous ne comptez pas sur le serveur pour vous "protéger".

— Dean Harding

2

@Jarrod - Cela me semble, cependant, que différents sites Web utilisant différents algorithmes de hachage côté client empêcheraient l'attaque décrite par cette bande dessinée. Un mot de passe largement réutilisé devient de nombreux mots de passe différents grâce à ces différents algorithmes de hachage. Ce calcul du hachage côté client n'empêche pas l'application d'autres types de sécurité, tels que l'envoi du hachage via une connexion sécurisée.

— Steve314

2

@ Steve314 mon point est que tout ce qui concerne le client est compromis par défaut. Vous pouvez hacher, hacher et hacher, si cela est fait sur le client et est transmis au serveur dans le serveur, clearil ne s'agit que d'une masturbation mathématique à ce stade. J'ai dû réparer un système dont j'avais hérité, conçu exactement comme vous le décrivez, ainsi que l'OP. Il était constamment piraté par des adolescents atteints de Wireshark. Nous ne l'avons verrouillé que lorsque nous avons REALcrypté, crypté et signé toutes les données utiles vers et depuis le serveur. La manipulation du compte s'est arrêtée et ne s'est plus jamais produite par la suite.

5

Il semble que votre plan pour vous protéger contre les sites non autorisés soit de demander aux sites non autorisés de mettre en place une meilleure sécurité. ?

— pc1oad1etter

46

Pourquoi n'est-il pas utilisé? Parce que c'est beaucoup de travail supplémentaire pour un gain nul. Un tel système ne serait pas plus sécurisé. Il est même peut-être moins sûr, car cela donne une fausse impression de sécurité, ce qui incite les utilisateurs à adopter des pratiques moins sécurisées (telles que la réutilisation des mots de passe, les mots de passe dictionnaires, etc.).

— Rein Henrichs
source

2

C'est la meilleure réponse à ce jour.

1

C'est comme le cryptage Blu-Ray et DVD. Il ne nécessite même pas de clé pour déverrouiller. La seule "protection" offerte était que, lors de la première sortie du DVD, cela coûtait plus cher d'acheter un disque pour le copier que d'acheter une copie intégrale du film. Bien sûr, vous pouvez maintenant acheter un dvd pour un dollar et plus encore, c'est que les clés sont maintenant connues du public. Même chose avec Blu-Ray

— Michael Brown,

2

Je pense que le hachage d'un mot de passe côté client ajoute la sécurité. Si j'écoute, je ne peux voir que votre dièse, pas votre mot de passe. Si le serveur envoie un défi (comme il se doit), le hachage n'est même pas réutilisable.

— Andomar

2

Je pense que l'approche de x4u pourrait très bien convenir à certaines applications où les exigences de sécurité se situent quelque part entre la transmission de mots de passe sur le réseau et l'utilisation de certificats. Je pense que certains des non-votants oublient que le hachage du mot de passe avant qu'il soit transmis sur le réseau est effectué en plus du traitement standard des informations d'identification côté serveur. La question est donc la suivante: la proposition de x4u améliore-t-elle la sécurité dans le scénario de transmission du mot de passe sur le réseau ou non? Je dis que oui. La clé pour y parvenir réside dans l'utilisation de sels par mot de passe.

— LOAS

6

Le moyen correct d'empêcher les attaques MITM est le chiffrement de bout en bout. TLS (https) existe: utilisez-le. N'inventez pas vos propres systèmes de cryptographie.

— Rein Henrichs

14

En théorie, cela n'apporte aucune sécurité supplémentaire, mais dans la pratique, cela peut être utilisé pour se protéger contre les "sites non autorisés" qui n'empiètent pas votre mot de passe sur le serveur.

Comment cela vous protège-t-il exactement? On dirait que tout ce que vous voulez faire est de hacher le mot de passe haché, ce qui est en quelque sorte inutile. Parce que le mot de passe haché deviendrait alors le mot de passe.

Il existe de nombreux sites sur Internet qui nécessitent des informations de connexion, et le seul moyen de se protéger contre la réutilisation des mots de passe est la "promesse" que les mots de passe sont hachés sur le serveur, ce qui n'est pas toujours vrai.

Pourquoi ne pas utiliser le même mot de passe pour plusieurs sites? La raison pour laquelle les sites Web hachent le mot de passe en théorie est d'empêcher l'accès à votre compte s'ils sont compromis. Utiliser le même mot de passe pour plusieurs sites Web est tout simplement stupide.

Si vous utilisiez javascript, tout ce que le "hacker" aurait à faire, c'est d'utiliser la même méthode pour les mots de passe hashed-hashed. Une fois que vous avez les informations hachées, c'est tout le temps qu'il faut pour calculer le mot de passe-> même hachage dans la base de données, ce qui empêche l'accès à un compte.

— Ramhound
source

1

Si votre navigateur la hache toujours de la même manière, alors oui votre hachage peut être utilisé comme mot de passe partout ailleurs. Mais que se passe-t-il si les navigateurs attribuent un sel au site (peut-être le domaine?) Avant de le hacher et de l'envoyer au site? Je pense que c'est une idée intéressante.

— Tesserex

2

si c'est sur le client, il est compromis, tout sel sur le client est bien visible, c'est une question illogique. si vous ne comprenez pas la réponse de @Ramhound, vous ne devriez pas écrire de code qui doit être sécurisé, et commencer à lire sur la sécurité et la cryptographie dès le début.

3

Lorsque vous citez l'affiche originale, veuillez formater le texte comme tel (sélectionnez le texte et utilisez l'icône de citation juste au-dessus de l'éditeur)

— Marjan Venema

1

Jarrod, suivez vos propres conseils et informez-vous un peu avant de faire des déclarations ridicules. Un homme au milieu de l'attaque est inutile contre les fonctions de hachage sécurisées avec une longueur de sel raisonnable. Et ma suggestion n’est en aucun cas «sécurité par obscurité», elle est en fait sûre sur la base de ce qui est actuellement connu et accepté par les experts dans ce domaine et elle est utilisée de la même manière dans de nombreux protocoles. Ce n'est pas mon invention, je viens d'appliquer une procédure bien comprise à la connexion à un site Web. Vos fausses hypothèses ne gagnent en rien le fait qu’elles sont évidemment partagées par beaucoup d’autres également.

— x4u

3

Si le client connaît le sel et qu'il est envoyé en clair depuis un serveur, tout ce qui se trouve au milieu le sait également. Jamais dit, je devais annuler le hachage, si vous connaissez le sel sur le client, alors n'est pas sécurisé.

11

Parce que cela ajouterait peu à aucune valeur. La raison en est que si votre base de données est piratée, le pirate informatique ne disposera pas d'une liste de mot de passe valide, mais simplement d'un hachage. Par conséquent, ils ne peuvent emprunter l'identité d'aucun utilisateur. Votre système n'a pas connaissance du mot de passe.

Secure provient des certificats SSL et d'une forme d'authentification. Je souhaite que mes utilisateurs fournissent un mot de passe afin que je puisse en calculer le hachage.

En outre, l'algorithme de hachage serait sur le serveur dans une zone plus sécurisée. En le mettant sur le client, il est assez facile d’obtenir le code source pour Javascript, même si ses fichiers de scripts cachés sont référencés.

— Jon Raynor
source

3

C'est la meilleure réponse. Vous devriez chiffrer au niveau de la couche de transport. Sans cela, le reste n'est pas sécurisé. Oui, vous pourriez écrire une fonction de chiffrement ... mais cette fonction serait visible par les utilisateurs finaux (malveillants). Utilisez SSL.

— pc1oad1etter

La sécurité d'un algorithme de hachage ne devrait pas dépendre du secret. Les algorithmes de hachage pour la sécurité doivent être des fonctions à sens unique: même si vous avez le code, il est difficile de l'annuler. Au contraire, vous devriez utiliser une bibliothèque de hachage bien connue, conçue uniquement pour les mots de passe. Si ce n'est pas bien connu, c'est presque certainement un buggy ou un mauvais choix.

— leewz

6

La solution est plus simple que cela. Certificats clients. Je crée un certificat client sur ma machine. Lorsque je m'inscris sur un site Web, nous établissons une poignée de main à l'aide de mon certificat client et du certificat du serveur.

Aucun mot de passe n'est échangé et même si quelqu'un pirate la base de données, il ne dispose que de la clé publique de mon certificat client (qui doit être salée et chiffrée par le serveur pour un niveau de sécurité accru).

Le certificat client peut être stocké sur une carte à puce (et chargé dans un coffre-fort en ligne sécurisé à l'aide d'un mot de passe principal).

La beauté de tout cela, c’est qu’elle supprime le concept de phishing: vous ne saisissez jamais de mot de passe dans un site Web, vous ne faites que toucher à ce site Web. Tout ce qu'ils obtiennent, c'est votre clé publique qui est inutile sans clé privée. La seule susceptibilité est de trouver une collision lors d'une poignée de main et cela ne fonctionnerait qu'une fois sur un seul site Web.

Microsoft a essayé de fournir quelque chose comme ceci dans Windows avec Cardspace et l'a soumis ultérieurement en tant que norme ouverte. OAuth est un peu similaire mais repose sur une "partie émettrice" intermédiaire. Les InfoCards, par contre, pourraient être auto-émises. C'est la vraie solution au problème de mot de passe ... supprimer les mots de passe tout à fait.

OAuth est cependant un pas dans la bonne direction.

— Michael Brown
source

5

Bien que les certificats clients constituent une approche raisonnable pour certains cas d'utilisation, ils ne peuvent pas être ajoutés facilement à la connexion à un site Web. Ils nécessitent une grande coopération des utilisateurs et dépendent de la sécurité de la clé privée de l'utilisateur. L'utilisation d'une clé privée peut être sécurisée ou pratique, mais pas les deux en même temps.

— x4u

5

la plupart des réponses ici semblent complètement passer à côté du point de hachage du mot de passe côté client.

le but n'est pas de sécuriser l'accès au serveur auquel vous vous connectez, car intercepter un hachage n'est pas plus sûr que d'intercepter un mot de passe en texte brut.

le but est vraiment de sécuriser le mot de passe de l'utilisateur , ce qui est généralement beaucoup plus précieux que l'accès de connexion de site individuel puisque la plupart des utilisateurs réutilisent leur mot de passe pour plusieurs sites (ils ne devraient pas, mais la réalité est qu'ils le font, il ne devrait pas être ignoré )

ssl est idéal pour la protection contre les attaques par mitM, mais si une application de connexion est compromise sur le serveur, ssl ne protégera pas vos utilisateurs. Si une personne a accédé de manière malveillante à un serveur Web, elle sera probablement en mesure d'intercepter les mots de passe en clair, car dans la plupart des cas, les mots de passe ne sont hachés que par un script du serveur. L'attaquant peut alors utiliser ces mots de passe sur d'autres sites (généralement plus précieux) utilisant des noms d'utilisateur similaires.

la sécurité est une défense en profondeur, et le hachage côté client ajoute simplement une autre couche. N'oubliez pas que, même s'il est important de protéger l'accès à votre propre site, il est beaucoup plus important de protéger le secret des mots de passe de vos utilisateurs en raison de la réutilisation du mot de passe sur d'autres sites.

— grincheux
source

2

La réponse acceptée partage très bien votre argument. Même si "la plupart des réponses" ne le font pas et parce que votre réponse n'ajoute pas vraiment beaucoup de valeur, il est inutile de ressusciter cette question.

— Frank

c'est probablement plus un commentaire qu'une réponse (excuses pour ne pas savoir comment ajouter du fil de commentaire de réponse acceptée), et même si mon point est partagé dans la réponse acceptée, il n'était apparemment pas assez clair puisque les réponses semblent brosser encore. merci pour les commentaires

— crutchy

@Frank, la réponse acceptée est trop longue pour être lue. cela donne trop de détails sur la façon dont cela peut être mis en œuvre et minimise les avantages vers la fin. Avoir un TL; DR dans une réponse différente est bénéfique.

— Jules

2

@Jules: C'est pourquoi l'édition existe.

— Robert Harvey

1

@JarrodRoberson Je pense que vous ne confondez plus la sécurité avec l' insécurité ? Si MITM se produit, l'accès au site est déjà abandonné, n'est-ce pas? Sauf si vous utilisez le certificat client au lieu du mot de passe, ce qui serait excessivement complexe pour les utilisateurs ordinaires. À mon sens, le hachage côté client évite que le même mot de passe soit compromis sur d'autres sites, en supposant que chaque algorithme de hachage est unique. Ce n'est peut-être pas plus sûr, mais ce n'est pas moins sécuritaire non plus? Alors, pourquoi appuyez-vous si fort sur cela? Je suis tombé sur cette méta et c’est la meilleure réponse que j’ai vue jusqu’à présent.

— zypA13510

1

C'est tout à fait possible et vous n'avez pas besoin d'attendre un site Web.

Jetez un coup d'œil à SuperGenPass . C'est un bookmarklet.

Il reconnaît simplement les champs de mots de passe, concatène ce que vous tapez avec le domaine du site Web, le hachage, le modifie quelque peu de manière à obtenir uniquement les caractères "admis" dans le mot de passe, et ce n'est qu'alors que votre mot de passe haché est envoyé sur le réseau.

En utilisant le domaine du site dans le processus, vous obtenez ainsi un mot de passe unique par site, même si vous réutilisez toujours le même mot de passe.

Ce n'est pas extrêmement sécurisé (base64-MD5), mais vous distribuez parfaitement une implémentation sha-2 si vous le souhaitez.

Le seul inconvénient est que si le domaine change, dans ce cas, vous devrez demander au site Web de réinitialiser votre mot de passe, car vous ne pourrez pas le récupérer par vous-même ... cela ne se produit pas souvent, alors compromis acceptable.

— Matthieu M.
source

C'est ce que je pensais en lisant la question. il est pratiquement inutile que les sites fassent leur propre hachage côté client, mais une extension de navigateur qui le fait (en utilisant du sel basé sur le domaine) annulerait efficacement les risques associés à la réutilisation du mot de passe. Bien sûr, la partie amusante survient lorsque vous essayez de vous connecter depuis une autre machine ...

— Aaronaught,

3

ce n'est plus sûr que tout autre système qui passe le mot de passe en clair. Cela rend le mot de passe unique, mais il n'est toujours pas crypté , mais si j'ai un serveur au milieu, je peux simplement récupérer le mot de passe compliqué mais toujours clair et l'utiliser comme je veux, il ne change pas. Un hachage n'est pas une solution miracle, il ne s'agit même pas d'un cryptage, mais d'un cryptage, mais cela ne signifie pas qu'il s'agit d'un cryptage. Peu importe si mon mot de passe est passwordet / ou un SHA-256 ou passwordavec un peu de sel qui est connu du client, un attaché au milieu peut le capturer.

@ Jarrod Roberson: vous pouvez bien sûr utiliser le mot de passe, mais vous ne pouvez pas le réutiliser pour un autre de mes comptes, ce qui est le cas. Par conséquent, si l'un des sites Web sur lequel je me connecte se fait voler sa base de mots de passe et qu'il les stocke en clair, mes autres comptes sont alors protégés.

— Matthieu M.

@Aaronaught: c'est là que ça brille en réalité. Étant donné que le mot de passe envoyé provient uniquement du domaine de site Web sur lequel vous vous connectez et d'un mot de passe principal de votre choix, vous pouvez vous connecter à partir de n'importe quel ordinateur (et navigateur) tant que vous avez le bookmarklet. C'est pourquoi c'est un peu plus confortable qu'un certificat.

— Matthieu M.

6

@Jarrod: Ce n'est pas une mesure de sécurité pour le site , c'est une mesure de sécurité pour l' utilisateur . Si tout le monde utilisait un tel système, la réutilisation des mots de passe ne poserait aucun problème. Un schéma MITM peut utiliser le mot de passe haché du client pour accéder à ce site, mais uniquement à ce site. C'est là que réside l'amélioration. Normalement, vous vous attendez à pouvoir accéder à de nombreux comptes en déchiffrant simplement un mot de passe, car ce mot de passe est susceptible d'être réutilisé. dans ce cas, il est pratiquement garanti que le mot de passe fissuré n'est valide que pour le site ou la base de données dans

— lequel

0

J'aime la réponse de X4u, mais à mon avis, quelque chose comme cela devrait être intégré au navigateur / à la spécification html - car, pour le moment, ce n’est que la moitié de la réponse.

Voici un problème que j'ai en tant qu'utilisateur - je ne sais pas si mon mot de passe sera haché à l'autre bout lorsqu'il sera stocké dans la base de données. Les lignes entre moi et le serveur sont peut-être cryptées, mais je n'ai aucune idée de ce qu'il advient de mon mot de passe une fois qu'il a atteint la destination. Il est peut-être stocké sous forme de texte brut. L’administrateur de la base de données finira peut-être par vendre la base de données et, avant même que vous le sachiez, le monde entier connaît votre mot de passe.

La plupart des utilisateurs réutilisent des mots de passe. Les gens non techniques parce qu'ils ne savent pas mieux. Personnel technique, car une fois que vous avez atteint le 15ème mot de passe, la plupart des gens n'ont aucune chance de les mémoriser à moins de les écrire (ce qui, nous le savons tous, est également une mauvaise idée).

Si Chrome ou IE ou tout ce que j'utilisais pouvait me dire qu'une boîte de mot de passe allait être instantanément hachée du côté client en utilisant un sel généré par le serveur et efficacement le mot de passe sandbox lui-même - alors je saurais qu'en tant qu'utilisateur, je pourrais le réutiliser un mot de passe avec moins de risque. Je voudrais toujours les canaux cryptés ainsi que je ne veux pas que les gouttières disparaissent pendant la transmission.

L'utilisateur doit savoir que son mot de passe n'est même pas disponible pour être envoyé au serveur - uniquement le hachage. À l'heure actuelle, même en utilisant la solution X4U, ils n'ont aucun moyen de savoir que c'est le cas, car vous ne savez pas si cette technologie est utilisée.

— Chris Nevill
source

1

il est intégré dans le navigateur, qui vérifie l'authentification Digest et vous verrez les étapes inverses effectuées en http pour obtenir un mot de passe haché, avec des informations supplémentaires et vérifié sur le serveur.

— gbjbaanb

-1

Je pense que c'est une bonne méthode à utiliser lors de la création de quelque chose comme un framework, un CMS, un logiciel de forum, etc., où vous ne contrôlez pas les serveurs sur lesquels il pourrait être installé. OUI, vous devez toujours recommander l'utilisation de SSL pour les connexions et les activités connectées, mais certains sites utilisant votre framework / cms ne l'auront pas, ils pourraient donc en tirer parti.

Comme d'autres l'ont souligné, l'avantage ici n'est PAS qu'une attaque MITM ne puisse permettre à quelqu'un d'autre de se connecter à ce site en tant que vous, mais plutôt que cet attaquant ne pourrait alors pas utiliser le même nom d'utilisateur / mot de passe pour connectez-vous à des dizaines d'autres sites sur lesquels vous pourriez avoir un compte.

Un tel schéma devrait utiliser un sel aléatoire ou une combinaison de sels spécifiques à un site et à un nom d'utilisateur, de sorte que le détenteur du mot de passe ne puisse pas l'utiliser pour le même nom d'utilisateur sur d'autres sites (même les sites utilisant le même schéma de hachage) ), ni contre les autres utilisateurs du site qui pourraient avoir le même mot de passe.

D'autres ont suggéré que les utilisateurs créent des mots de passe uniques pour chaque site qu'ils utilisent ou utilisent des gestionnaires de mots de passe. Bien que ce soit un conseil judicieux en théorie, nous savons tous que c’est une folie sur laquelle compter dans le monde réel. Le pourcentage d'utilisateurs qui font l'une ou l'autre de ces choses est faible et je doute que cela change bientôt.

Donc, un hasher de mot de passe javascript est le moins du monde qu'un développeur framework / cms peut faire pour limiter les dommages d'une personne interceptant des mots de passe en transit (ce qui est facile sur les réseaux wifi de nos jours) si le propriétaire du site et les utilisateurs finaux sont négligents sur la sécurité (ce qu’ils sont probablement).

— matthewv789
source