Le hachage côté client ne résout pas le principal problème que le hachage de mot de passe est destiné à résoudre - ce qui se passe si un attaquant accède à la base de données de mots de passe hachés. Étant donné que les mots de passe (hachés) envoyés par les clients sont stockés tels quels dans la base de données, un tel attaquant peut se faire passer pour tous les utilisateurs en envoyant au serveur les mots de passe hachés de la base de données tels quels.

D'autre part Par contre, le hachage côté client est agréable en ce qu'il garantit à l'utilisateur que le serveur n'a aucune connaissance du mot de passe - ce qui est utile si l'utilisateur utilise le même mot de passe pour plusieurs services (comme le font la plupart des utilisateurs ).

Une solution possible pour cela est le hachage à la fois du côté client et du côté serveur. Vous pouvez toujours décharger la lourde opération PBKDF2 sur le client et effectuer une seule opération de hachage (sur le mot de passe haché PBKDF2 côté client) côté serveur. Le PBKDF2 dans le client empêchera les attaques par dictionnaire et l'opération de hachage unique côté serveur empêchera d'utiliser les mots de passe hachés d'une base de données volée tels quels.

Il y a peu de temps où le hachage côté client en vaut la peine. Une telle circonstance est lorsque le processus de hachage est intensif en calcul, ce qui peut être le cas avec PBKDF2.

Répondre à vos préoccupations:

1. Évitez suggestions non validées sur la cryptographie que vous trouvez sur Internet. (Clause de non-responsabilité: je ne suis pas Bruce Schneier.)
2. Les sels déterministes ne sont pas un problème - la seule vraie exigence du sel est qu'il soit unique pour chaque utilisateur. Le véritable objectif du sel est d'empêcher qu'une force brute sur un mot de passe ne se transforme en force brute sur tous les mots de passe dans le cas d'une base de données compromise. Même si vous deviez stocker un sel aléatoire dans votre base de données juste à côté du mot de passe haché, vous atteindriez toujours cet objectif, à condition que chaque utilisateur soit différent.
3. Comme je l'ai mentionné ci-dessus, PBKDF2 est bien parce que vous pouvez arbitrairement décider de la difficulté de calcul du hachage. Vous pouvez sélectionner un c de sorte qu'un hachage unique sur du matériel moderne ne prenne que quelques secondes, ce qui élimine efficacement le risque d'attaque par force brute au niveau de l'API. (Bien sûr, vos clients pourraient ne pas profiter d'un si long délai de connexion.)
4. Un utilisateur peut choisir des mots de passe simples - ils ne font que se blesser. Si vous vouliez éliminer ce risque, vous demanderiez au serveur de générer le hachage la première fois, à condition que le mot de passe passe par un canal chiffré.
5. Oui, et vous devrez également les saler de manière unique. En cas de compromission de la base de données, vous voulez vous assurer que l'attaquant n'obtient pas d'informations lui permettant de s'authentifier directement en tant qu'utilisateur de votre système. Une mise en garde ici est que vous ne voulez pas que votre hachage côté serveur soit intensif en calcul comme l'est votre hachage côté client. Si votre hachage côté serveur demande trop d'efforts, vous vous exposez à un vecteur d'attaque par déni de service épuisant du processeur - un attaquant envoie simplement des tentatives d'authentification par mot de passe vides sur Tor, des mots de passe que votre serveur doit essayer de hacher avant de savoir qu'ils sont frauduleux, vous laissant finalement avec un serveur débordé.

Si vous hachez le mot de passe côté client, quel que soit le résultat EST le mot de passe, vous ne gagnez donc pas de réelle sécurité. Tout piratage ou fuite d'informations qui aurait révélé le mot de passe en texte brut révélera à la place le mot de passe haché, qui est le vrai mot de passe.

Cela ne doit pas être confondu avec les schémas d'authentification à connaissance nulle, où un échange de messages prouve que le client connaît le vrai mot de passe, sans le transmettre réellement.

Il semble que vous essayez d'inventer votre propre protocole cryptographique. D'après la description de votre approche, il ne semble pas que vous ayez les connaissances nécessaires pour le faire de manière sécurisée. Je recommande vivement d'utiliser les protocoles existants au lieu de créer les vôtres.

Premièrement, le modèle de menace que vous pensez contourner n'est pas clair. Vous citez ce qu'on appelle une "attaque de rétro-ingénierie" qui n'a pas de définition ou de signification réelle.

Deuxièmement, votre compréhension du but d'un sel et des meilleures pratiques pour sa génération semble faire défaut. Les sels ne doivent pas être tenus secrets. Vous pouvez (et devriez) générer un sel unique à partir d'un CSPRNG pour chaque nouveau jeton d'authentification, et non à partir de quelque chose comme une adresse e-mail (qui pourrait changer). Les sels spécifiques aux applications fixes sont parfois appelés "piments", et je ne connais aucune littérature cryptographique qui soutienne ou encourage leur utilisation.

Troisièmement, PBKDF2 est correct, mais sérieusement, utilisez simplement BCrypt. BCrypt a été conçu pour cela et est largement utilisé. De bonnes implémentations de BCrypt gèreront la génération de sel et l'étalonnage / détection automatique du facteur de travail pour vous. Vous devrez implémenter ces choses vous-même pour utiliser PBKDF2, et vous ferez presque inévitablement des erreurs.

Quatrièmement, il existe une approche existante de ce que vous semblez essayer de faire. L'authentification sans connaissance peut être effectuée avec SRP. Le mot de passe de l'utilisateur n'est jamais transmis sur le fil, et un homme au milieu ne peut rien renifler d'utile pour s'authentifier. Cependant, il est apparemment difficile de l'implémenter correctement et il n'y a pas beaucoup de bibliothèques existantes pour le faire, ce qui devrait vous donner une indication de la difficulté du problème.

En bref: n'inventez pas votre propre crypto. Utilisez des solutions et des protocoles largement mis en œuvre et qui ont résisté à l'épreuve du temps.

Le hachage sur le client peut être une bonne idée dans certaines circonstances et pour certaines raisons, mais je ne ferais pas de la "tranquillité d'esprit de l'utilisateur" l'une d'elles. Je suis tout à fait pour que les utilisateurs soient dans un état d'esprit harmonieux et en union avec l'Univers, mais je trouve douteuse l'idée de promouvoir un moyen d'inciter les utilisateurs à réutiliser le même mot de passe sur plusieurs sites.

Un bon cas pour le hachage côté client est le fonctionnement de certains "coffres-forts de mots de passe": ils calculent un mot de passe spécifique au site en hachant le "mot de passe principal" de l'utilisateur avec le nom du site. Cela donne la plupart de la possibilité d'utiliser toujours le même mot de passe partout, sans donner réellement votre mot de passe principal à des dizaines de sites distincts. Mais cela ne fonctionne que tant que l'algorithme de dérivation du mot de passe est générique et ne change pas; cela semble être beaucoup mieux traité par une extension de navigateur Web que par une applet provenant des sites eux-mêmes (tous les sites devraient coopérer pour utiliser des applets utilisant le même algorithme de dérivation de mot de passe, avec des données spécifiques au site).

Un autre bon cas pour le hachage de mot de passe côté client est l'utilisation d'un hachage lent (afin de rendre le piratage de mot de passe plus difficile pour un attaquant qui pourrait récupérer une copie de la base de données de hachage mots de passe); il est tentant d'essayer de décharger le coût sur le client, car, lorsque le client veut se connecter, il est généralement inactif et activement intéressé à se connecter. Cependant, le hachage lent est une course aux armements entre l'attaquant et le défenseur. L'utilisation de Java induira un ralentissement (d'un facteur typique de 3), et certains systèmes clients peuvent être assez faibles (par exemple, des smartphones bon marché ou des ordinateurs vieux de dix ans). C'est comme prendre une épée au lieu d'un fusil d'assaut avant d'entrer dans une bataille où l'adversaire apportera un char.

Mais si ce que vous voulez, en tant qu'utilisateur, c'est protéger votre mot de passe contre les procédures de stockage bâclées par un site, alors la bonne façon de le faire est de choisir un mot de passe différent pour chaque site . (Personnellement, je garde un fichier de mots de passe, et tous mes mots de passe sont générés aléatoirement.)

Un employé de Google travaille sur quelque chose de similaire appelé TLS-OBC. Ce projet RFC permet au client de hacher le mot de passe et de le lier à une session TLS.

Plus précisément, vous pourriez être intéressé par ce site Web http://www.browserauth.net/origin-bound-certificates

et ce lien sur Strong User Authentification http://www.browserauth.net/strong-user-authentication

::Update

OBC et peut-être l'autre est maintenant intégré dans la norme d'authentification FIDO.

Le hachage du mot de passe permet d’empêcher quiconque sauf l’utilisateur d’apprendre le mot de passe. Les gens réutilisent les mots de passe et ils ne sont généralement pas très forts s'ils sont mémorisés. C'est pourquoi nous nous préoccupons des hachages lents (Bcrypt, Scrypt, Argon2, etc.) au lieu d'un hachage rapide: il protège mieux le mot de passe de l'utilisateur, même s'il n'a aucun avantage pour l'application. Un avantage secondaire du hachage par le serveur d'un mot de passe entrant avant de le stocker dans la base de données est que quelqu'un qui compromet la base de données ne peut se connecter avec aucune des valeurs trouvées (il doit d'abord les casser).

Nous voulons conserver les deux avantages. Pour cela, nous devons hacher sur le client (lent) et le serveur (rapide).

Pourquoi sur le serveur?
De sorte qu'un attaquant qui a obtenu la base de données ne peut pas utiliser les données obtenues pour se connecter. Si votre client effectue déjà un hachage lent, il peut s'agir d'un seul cycle d'un algorithme de hachage sécurisé (comme SHA-3 ou BLAKE2).

Pourquoi sur le client?

1. Transparence
   Chaque fois qu'une entreprise est piratée, nous devons espérer qu'elle nous dira comment les mots de passe ont été haché, voire pas du tout. Il y a encore des endroits qui les stockent en clair, ou utilisent un algorithme rapide, ou ne les salent pas, etc. En faisant du hachage côté client, les personnes intéressées peuvent voir comment cela est fait et éviter les questions comme celles-ci. Ma mère ne le vérifiera pas, mais ma mère ne vérifie pas non plus le TLS d'un site Web à la recherche de saignements de cœur: les "hackers éthiques" ou les pirates blancs le font.

2. Déchargez le serveur
   Le risque de faire des hachages très lents sur le serveur est qu'un attaquant puisse l'utiliser pour une attaque par déni de service: si le serveur a besoin de 2 secondes pour traiter chaque tentative de connexion, les attaquants ont un énorme avantage à tenter de le supprimer. En faisant le hachage lent sur le client (dont le processeur est de toute façon inutilisé 99% du temps, et ce n'est pas comme si la plupart des gens se connectaient à quelque chose plus de quelques fois par jour), vous déchargez le serveur, vous permettant de choisir des hachages plus lents sans risquer qu'un attaquant arrête votre serveur.

3. Réduire l'impact d'une transmission compromise
   Si le canal de transmission sécurisé échoue pour une raison quelconque, par exemple un bogue dans TLS (juin 2020: "Oups, pour les 10 dernières versions, la plupart des connexions TLS 1.0-1.2 pouvaient être décryptées passivement"), l'impact est réduit car un attaquant ne pourrait observer que les hachages au lieu du mot de passe d'origine . Cela s'applique également lorsque quelqu'un est capable de déchiffrer un flux chiffré des années plus tard, par exemple parce que RC4 est maintenant connu pour être cassé il y a plus de quelques années.
   Notez que dans le bogue de juin 2020, l'authentification ne semble pas être affecté, les attaquants n'auraient donc pas pu modifier les fichiers JavaScript pour supprimer le hachage. Maintenant, je me demande quels mots de passe j'ai utilisés depuis des mois sur https et si l'une de ces connexions a pu être interceptée passivement.

4. Améliorer la norme
   pour que nous puissions voir la mise en œuvre de tout le monde, il y aura un débat sur qui a obtenu le plus long et qui a obtenu le meilleur. Cette discussion pousse définitivement les mauvais à faire mieux, et elle aboutit probablement aussi à une normalisation. Ce serait vraiment chouette si vous pouviez simplement ajouter un paramètre à l'élément d'entrée de mot de passe, comme <input type = password hash = v1> , ce qui ferait tout le hachage pour vous (il salerait avec le nom de domaine et le champ du nom d'utilisateur, mais tous ces détails de cette proposition sortent du cadre de cette réponse).

5. Détection de compromission
   Un argument courant est que "si le serveur est compromis, les attaquants pourraient supprimer le code JavaScript responsable du hachage du mot de passe, permettant aux attaquants d'obtenir de toute façon le texte en clair". Cet argument n'est valable que pour les sites Web, mais les gens ne le mentionnent généralement pas, ce qui fait que personne ne hache non plus côté client dans les applications. Ce qu'ils oublient également, c'est que si le hachage côté client est courant, les chercheurs en sécurité peuvent commencer à l'utiliser: il y aura des personnes qui analyseront des sites Web importants pour voir si le hachage est toujours là (ce serait tout à fait l'indicateur de compromis si PayPal supprime hachage côté client (dans le cas hypothétique où ils feraient un hachage côté client en premier lieu)), et il pourrait y avoir des extensions de navigateur (ou des fonctionnalités intégrées) qui vous avertissent s'il est supprimé, tout comme nous avertissons pour la connexion formulaires sur les pages http.

6. Pas d'espionnage secret
   Même s'ils hachent la base de données, les employés peuvent intercepter le mot de passe avant qu'il ne soit haché et stocké (en se connectant à un TLS point de terminaison ou en installant du code supplémentaire). Il y a suffisamment d'histoires d'employés aigres, voire d'adolescents qui construisent une application et veulent savoir quels sont les mots de passe de leurs utilisateurs.

7. Pas d'e-mails en clair
   Si le serveur ne le fait pas avoir votre mot de passe, ils ne peuvent pas vous envoyer d'email du type "Merci de vous être inscrit, votre nom d'utilisateur et votre mot de passe sont xxx". Les e-mails sont généralement considérés comme non sécurisés, mais il existe encore des sites Web qui le font.

8. Aucune exposition accidentelle
   Il y a eu un incident assez récent où des mots de passe ont été accidentellement écrits dans des fichiers journaux. Je ne mentionnerai pas le nom de l'entreprise car je ne pense pas que ce soit pertinent, mais c'était une grande entreprise de technologie avec une équipe de sécurité dédiée et tout. Des accidents comme ceux-ci se produisent simplement et cela a eu des retombées médiatiques assez importantes. Il y a en outre une exposition dans de nombreux réseaux où un système séparé effectue la terminaison TLS puis envoie la demande en clair à d'autres systèmes, permettant à n'importe quel boîtier réseau de voir les mots de passe (Google avait l'habitude de le faire jusqu'à ce qu'ils aient vent de la NSA ayant des interceptions dans leur interne. réseau). Les interceptions de mot de passe "en texte clair" seraient moins problématiques si nous faisions le hachage avant que le mot de passe n'atteigne le réseau.

9. Pourquoi pas?
   Je ne vois aucune raison pourquoi vous ne devriez pas le faire, en supposant que vous fassiez en plus un hachage rapide sur le serveur (pour obtenir cet avantage secondaire mentionné dans le premier paragraphe). Même si vous pensez qu'une seule des raisons est convaincante, alors ce serait toujours une amélioration.

Je pense que la seule raison pour laquelle le hachage côté client n'est pas commun, c'est parce que c'est rare. Chaque fois qu'il est proposé, les gens se demandent pourquoi c'est si rare s'il n'y a que des avantages. La décision de ne faire que le hachage côté serveur semble souvent rationalisée. Voici quelques-uns des arguments que j'ai entendus auparavant:

• "Un attaquant supprimerait simplement le code responsable du hachage!" Cela s'applique uniquement aux applications Web. Les applications normales (parmi lesquelles les applications mobiles) ne présentent pas ce problème.
• "Mais mon cas s'applique à une application Web!" Si le hachage côté client était courant pour les applications Web, nous verrions probablement une normalisation (pensez à <input type = password hashversion = 1> ) similaire à la façon dont les langages et les frameworks ont des fonctions de hachage standard que les développeurs peuvent utiliser. Si un champ est envoyé en texte clair, le navigateur peut l'indiquer. Nous pouvons facilement normaliser cela, mais seulement si les développeurs expriment réellement l'intention de le faire et que nous choisissons de nous en soucier.
• "Mais quel que soit le résultat [du hachage côté client], c'est le mot de passe!" Si votre base de données de connexion est compromise, il est peu probable qu'un attaquant ait encore besoin de se connecter à votre application pour en récupérer toutes les données. La défense en profondeur de la plupart des systèmes n'est vraiment pas si bonne, mais même si c'est le cas, l'argument est nul car le conseil est de faire un hachage rapide supplémentaire sur le serveur.
• "Vous devriez simplement utilisez un gestionnaire de mots de passe au lieu de vous fier à la sécurité des hachages! " Je suis d'accord, ce serait idéal. Authentification à deux facteurs partout, utilisée par tout le monde, avec des gestionnaires de mots de passe et des cartes à puce ... ouais, quand ce jour viendra, nous n'avons plus du tout besoin de hachage de mot de passe. Vous devriez toujours faire un hachage rapide sur le serveur pour l'avantage secondaire susmentionné, mais nous pouvons arrêter de faire des algorithmes de hachage lents et du hachage côté client car personne ne réutiliserait les mots de passe de toute façon.
• "Vous ne devriez pas mettre l'utilisateur en charge de la sécurité! " Ils sont déjà en charge de la sécurité: vous pouvez toujours choisir d'avoir 123456 comme mot de passe (ou s'il y a des exigences idiotes, vous pouvez toujours faire "Bailey2009!"). Vous pouvez également publier les clés de votre connexion TLS et annuler sa sécurité. L'utilisateur pourra toujours gâcher la sécurité que vous implémentez s'il le souhaite.
• "Mais comment allez-vous saler le hachage?" Le champ du nom d'utilisateur, peut-être combiné avec un nom de domaine ou d'entreprise pour le rendre unique au monde. Un sel n'est pas secret, seulement unique, tout comme le champ de votre nom d'utilisateur.