Pourquoi le hachage côté client d'un mot de passe est-il si rare?
Il existe très peu de sites Web qui hachent le mot de passe des utilisateurs avant de le soumettre au serveur. Javascript n'a même pas de support pour SHA ou d'autres algorithmes.
Mais je peux penser à quelques avantages, comme la protection contre les fuites intersites ou les administrateurs malveillants, que SSL ne fournit pas.
Alors pourquoi cette pratique est-elle si rare parmi les sites Web?
Inventeur du hachage de mot de passe JavaScript ici
En 1998, je construisais un Wiki, le premier site Web que j'avais construit avec un système de connexion. Il n'y avait aucun moyen que je puisse me permettre d'héberger avec SSL, mais je m'inquiétais des mots de passe en texte brut passant sur Internet. J'avais lu sur CHAP (protocole d'authentification par hachage de défi) et réalisé que je pouvais l'implémenter en JavaScript. J'ai fini par publier JavaScript MD5 en tant que projet autonome et il est devenu l'open source le plus populaire que j'ai développé. Le wiki n'a jamais dépassé alpha.
Comparé à SSL, il présente un certain nombre de faiblesses:
- Protège uniquement contre l'écoute passive. Un MITM actif peut altérer le JavaScript et désactiver le hachage.
- Les hachages côté serveur deviennent des équivalents de mot de passe. Au moins dans la mise en œuvre commune; il existe des variations qui évitent cela.
- Les hachages capturés peuvent être forcés brutalement. Il est théoriquement possible d'éviter cela en utilisant JavaScript RSA.
J'ai toujours énoncé ces limitations dès le départ. J'étais régulièrement flambé pour eux. Mais je maintiens le principe d'origine à ce jour: si vous n'avez pas SSL pour quelque raison que ce soit, c'est mieux que les mots de passe en clair. Au début des années 2000, un certain nombre de grands fournisseurs (notamment Yahoo!) L'utilisaient pour les connexions. Ils pensaient que SSL, même juste pour les connexions, aurait trop de frais généraux. Je pense qu'ils sont passés au SSL uniquement pour les connexions en 2006, et vers 2011, lorsque Firesheep a été publié, la plupart des fournisseurs sont passés au SSL complet.
Donc, la réponse courte est: Le hachage côté client est rare car les gens utilisent SSL à la place.
Il existe toujours des avantages potentiels du hachage côté client:
- Certains logiciels ne savent pas s'ils seront déployés avec SSL ou non, il est donc logique d'inclure le hachage. vBulletin en était un exemple courant.
- Soulagement du serveur - avec des hachages coûteux en calcul, il est logique que le client fasse une partie du travail. Voir cette question .
- Administrateurs malveillants ou serveur compromis - le hachage côté client peut les empêcher de voir les mots de passe en texte brut. Ceci est généralement rejeté car ils pourraient modifier le JavaScript et désactiver le hachage. Mais en toute justice, cette action augmente leurs chances d'être détecté, il y a donc un certain mérite à cela.
En fin de compte, bien que ces avantages soient mineurs et ajoutent beaucoup de complexité - il existe un risque réel que vous introduisiez une vulnérabilité plus grave dans votre tentative d'améliorer la sécurité. Et pour les personnes qui souhaitent plus de sécurité que le mot de passe, l'authentification multifacteur est une meilleure solution.
La deuxième réponse courte est donc: car l'authentification multifacteur offre plus de sécurité que le hachage de mot de passe côté client.
Pour comprendre ce problème, vous devez d'abord comprendre pourquoi nous hachons les mots de passe. Il est tout à fait possible de stocker un mot de passe en texte brut sur un serveur et de comparer simplement le mot de passe transmis au mot de passe reçu. Tant que le mot de passe est protégé en transit, il s'agit d'un moyen d'authentification sécurisé (secret partagé).
La raison pour laquelle les mots de passe sont hachés est que le problème n'est pas l'authentification, mais le stockage. Si le serveur est jamais compromis, l'attaquant aurait immédiatement accès à tous les comptes d'utilisateurs car il connaîtrait désormais le secret utilisé pour l'authentification des utilisateurs.
Le hachage agit comme un obstacle à cela. Étant donné que le serveur ne connaît pas l'entrée réelle requise pour l'authentification, même un compromis sur la base de données n'accorde pas à un attaquant l'accès aux comptes d'utilisateur. Ils auraient encore besoin de comprendre l'entrée à donner pour atteindre les valeurs de hachage auxquelles l'application vérifie. Bien sûr, ils pourraient modifier toutes les valeurs en quelque chose qu'ils savent, mais cela jetterait rapidement le soupçon et le système serait arrêté et sécurisé.
Ainsi, le problème avec le hachage côté client est qu'il fait effectivement du résultat du hachage le mot de passe plutôt que le mot de passe. Il n'y a rien pour empêcher un attaquant de contourner le client officiel et d'envoyer simplement le hachage fini au serveur directement. Il n'offre aucune sécurité (ou perte) supplémentaire pendant l'authentification, mais dans la situation contre laquelle le hachage est conçu pour se protéger, il n'offre rien car le hachage stocké dans la base de données est en fait le secret partagé transmis au serveur.
Cela dit, il y a deux choses notables que le hachage côté client vous donne. Bien que cela n'aide pas du tout à protéger votre système, cela peut aider à protéger votre utilisateur. Si vous transmettez le mot de passe de manière non sécurisée ou si la transmission est compromise sans que le code client ne soit compromis, vous protégerez toujours le mot de passe de l'utilisateur (qu'il peut réutiliser sur d'autres sites) contre les fuites.
L'autre est que vous pouvez fournir des itérations supplémentaires d'un hachage pour rendre une attaque hors ligne contre la base de données plus difficile sans avoir à utiliser des cycles de serveur (tout en étendant également la longueur du "mot de passe intermédiaire que le client soumet"), mais vous avez toujours besoin suffisamment de cycles de serveur pour protéger le mot de passe prolongé contre un client escroc. Encore une fois, la protection principale que cela offre empêche la découverte du mot de passe d'origine mais ne fait rien pour aider à protéger le mécanisme d'authentification de votre site.
Autrement dit, bien qu'il offre quelques protections mineures, du point de vue du serveur, le hachage côté client doit être traité comme s'il s'agissait du mot de passe direct de l'utilisateur. Il n'offre ni plus ni moins de sécurité sur le serveur que si l'utilisateur avait directement donné son mot de passe et devait être protégé comme tel.
Si vous voulez être en mesure de fournir ce niveau de sécurité supplémentaire, je recommanderais deux hachages. Hachez une fois côté client pour créer un nouveau mot de passe unique, puis hachez ce mot de passe sur le serveur pour créer une valeur que vous stockez dans la base de données. De cette façon, vous obtenez le meilleur des deux mondes.
Pour la plupart, SSL est suffisamment fiable pour protéger l'échange que le hachage initial avant la transmission est considéré comme inutile cependant et un serveur compromis pourrait toujours modifier le code envoyé au client de sorte que le hachage initial ne soit pas effectué. Ce n'est tout simplement pas une alternative efficace à SSL et n'offre pas suffisamment d'avantages supplémentaires pour valoir les coûts et la complexité.
Si vous avez un certain nombre d'avantages, vous devez les énumérer dans votre question afin que les gens découvrent s'ils sont vraiment utiles (et vous pouvez devenir célèbre si c'est le cas;)
Les utilisateurs ne sont pas favorables au hachage côté client, car ils disposent de meilleurs moyens de protéger les informations privées des utilisateurs. Pensons aux endroits avec des fuites d'informations potentielles et il y en a trois:
- Le client.
- Entre le client et le serveur.
- Le serveur.
Voyons ensuite pourquoi ou pourquoi pas le hachage côté client sera utile à ces endroits.
Le client.
S'il y a des malwares sur votre propre ordinateur, par exemple, si votre navigateur est compromis ou votre ordinateur est implanté avec un logiciel d'enregistrement de clé, le hachage côté client n'empêche pas un pirate d'obtenir votre mot de passe. La raison est évidente.
Entre le client et le serveur.
Il y a le canal de communication entre le client et le serveur. S'il y a un écouteur qui écoute la communication, le hachage côté client peut rendre la fuite de mot de passe plus difficile car l'écouteur doit récupérer le mot de passe d'origine à partir de son hachage. C'est effectivement utile ici.
Cependant, cette vulnérabilité est basée sur la présupposition d'un canal de communication non sécurisé. En réalité, il existe des protocoles dont l'existence tente de résoudre exactement ce problème. Leur tâche principale est d'établir un canal sécurisé sur un canal non sécurisé. L'exemple le plus célèbre et le plus largement déployé est SSL/TLS, et il offre plus de fonctionnalités et une meilleure sécurité que le hachage côté client.
La conclusion est que le hachage côté client est utile dans le canal, mais voici de meilleurs outils.
Le serveur.
Les informations des utilisateurs peuvent être divulguées sur le serveur si le serveur est compromis par un pirate. Le pirate peut extraire les mots de passe des utilisateurs de la base de données s'ils sont stockés en texte brut. C'est pourquoi aujourd'hui la plupart des serveurs ne font pas cela. Au lieu de cela, ils stockent des hachages de mots de passe afin que les pirates ne puissent pas facilement restaurer les mots de passe d'origine à partir de leurs informations à portée de main (c'est-à-dire des hachages).
Vous pourriez être tenté de croire que les choses fonctionnent toujours bien si le serveur stocke simplement des hachages calculés côté client. Mais c'est gravement faux. Dans cette situation, les hachages eux-mêmes deviennent des équivalents de mot de passe. Le pirate peut passer l'authentification en remettant simplement le hachage sans l'inverser. Le but d'un pirate n'est pas d'inverser un hachage, mais de s'introduire dans votre compte. L'importance réside dans le processus de vérification du serveur sur les données client, et non sur le fait que les données sont une valeur de hachage. Par conséquent, l'avantage du hachage côté client est trivial ici et le serveur doit quand même ressasser.
Pour résumer, le hachage côté client est utile pour protéger les informations utilisateur, mais la protection s'applique en grande partie au canal de communication. Puisque nous avons de meilleures approches là-bas (SSL/TLS), l'application du hachage côté client est grandement surpressée. Ce n'est tout simplement pas le meilleur outil pour la tâche à accomplir.
Quels avantages aurait le hachage de mot de passe côté client?
Eh bien, le mot de passe ne serait pas envoyé sur le net en texte clair. Mais vous devez vraiment utiliser le cryptage TLS lorsque vous vous connectez, donc le reniflage de mot de passe ne devrait pas être un problème.
Une autre raison pourrait être que vous ne voulez pas que le serveur jamais connaisse le mot de passe des utilisateurs, pas même pendant une microseconde. Cela signifie que vous attribuez au serveur le hachage de mot de passe lors de l'inscription, puis vous connectez à l'aide de ce hachage de mot de passe. Malheureusement, cela ne résout rien: le secret partagé pour se connecter au compte est maintenant le hachage, pas le mot de passe. Lorsque vous obtenez une connaissance du hachage, vous pouvez vous connecter sans connaître le mot de passe réel (car le serveur ne le connaît pas non plus).
Il est recommandé de hacher côté client, puis de saler le mot de passe et de hacher à nouveau côté serveur. Il s'agit d'une couche supplémentaire de protection contre l'homme au milieu des attaques. SSL est la première couche, mais les révélations de Snowden ont clairement montré que SSL peut être compromis par des organisations telles que le NSA avec une relative facilité.
Puisque vous parlez d'application web ...
Dans une base de données, nous avons une table appelée dbo.useracc, nous stockons ces mots de passe de hachage
User Password
-------- ----------
user1 5f4dcc3b5aa765d61d8327deb882cf99
user2 202cb962ac59075b964b07152d234b70
user3 098f6bcd4621d373cade4e832627b4f6
et notre fonction de connexion dans l'application Web est quelque chose comme
if (user == $user and password == $pass) {
return auth.token
}
Disons qu'un attaquant a réussi à pirater et à voler la base de données et a enregistré nos données dbo.useracc. Il a maintenant notre mot de passe haché.
Si votre processus de hachage de connexion est stocké dans le client, l'attaquant peut toujours accéder à votre compte avec le mot de passe haché en connectant simplement la méthode HTTP POST modifiant le champ de mot de passe pour envoyer votre mot de passe haché et il N'oubliez pas que les données de votre application communiquent avec le serveur via la méthode POST éventuellement après avoir été hachées pour être vérifiées.
Cependant, si le processus de hachage est sur le serveur, c'est une autre histoire.
$pass = md5.hash($pass);
if (user == $user and password == $pass) {
return auth.token;
}
Si le pirate utilise le mot de passe haché pour se connecter, ce sera un "mot de passe haché" comparé à un mot de passe haché.
Dans ce cas, disons que le post de l'attaquant
$ user = user1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99
Une fois que le côté serveur a fait $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99), il retournera '696d29e0940a4957748fe3fc9efd22a3' qui renvoie une fausse déclaration.
Il s'agit de bloquer l'attaquant qui a réussi à voler les données de la base de données et à essayer d'accéder via l'application Web à l'aide du mot de passe haché. Et bien sûr, l'attaquant peut toujours pirater les comptes s'il réussit à forcer/casser les hachages par le biais d'attaques de dictionnaire, etc. Cependant, le pirate nécessite plus de temps si le mot de passe est un bon mot de passe après avoir compromis le système et l'administrateur du serveur pourrait simplement réinitialiser le mot de passe et envoyer un e-mail aux utilisateurs.
Il est également utilisé pour les menaces internes comme les employés d'une entreprise. Dans une entreprise, il y aura un administrateur de base de données et des développeurs. Ce sont des rôles différents. Désormais, pour empêcher les utilisateurs des employés d'accéder aux données sensibles, ils doivent avoir accès à la fois à l'application et à la base de données pour accéder aux données. Bien sûr, vous pourriez faire valoir qu'un DBA peut toujours modifier les données de la base de données via la base de données elle-même, mais elle n'est pas accessible aux développeurs et il est plus facile de déterminer d'où vient l'attaque. Il s'agit de contrôler les droits d'accès et de minimiser les risques et les menaces.
Bien que le sujet ait des points de fuite concrets, comme l'a souligné @Cyker, la discussion est un peu vive ici ... Je voudrais ajouter un point que je n'ai pas vu mentionné.
C'est simplement que si vous hachez dès que possible, vous réduisez les risques de programmation de passer accidentellement un mot de passe en texte clair quelque part où il ne devrait pas aller. Nous prenons déjà des mesures comme des chaînes et des tableaux sécurisés pour essayer de détruire le texte clair dès que possible; et le hachage au moment où vous obtenez le mot de passe est une autre mesure comme ça ... Au fur et à mesure que le code évolue, etc. les risques semblent toujours être réduits.
Je viens d'écrire une petite "boîte" C # qui prend le texte clair de SecureString et le hache immédiatement --- de cette façon, je sais simplement qu'il ne sera jamais enregistré ou transmis à une bibliothèque à laquelle je ne m'attends pas. Il ne s'agit pas tant d'un protocole que du programmeur assis et regardant un mot de passe --- Je ne veux pas le toucher! (C'est toujours un mot de passe équivalent à certains égards, mais il est au moins immédiatement caché de la folie comme déplacer une parenthèse fermante dans un appel de méthode enchaîné et passer du texte clair au mauvais endroit. Et un tableau sécurisé n'est toujours pas caché.)
Je vais intervenir ici dans le but exprès de peser en faveur du mécanisme de hachage côté client. Voyons comment cela nous profite:
Côté client: aucune amélioration.
En transit: protège le mot de passe en cas de SSLstrip dans lequel le mot de passe finit par être transmis en texte clair. Cependant, si HSTS est implémenté, la plupart des gens diraient que SSLStrip n'aurait aucun effet. Droite? Non.
À l'entrée sur le serveur: Enfin, nous voyons le principal avantage. Que se passe-t-il si quelqu'un a compromis le serveur? Ils obtiennent un flux continu de mots de passe en texte clair s'ils démarrent simplement Wireshark/TCPDump et exportent la clé privée du serveur. Maintenant, ils peuvent rester sur le fil pendant quelques mois, et pour les serveurs à volume élevé (millions d'enregistrements d'utilisateurs par mois), ils obtiennent leur énorme violation de texte en clair. Cela suppose qu'il est plus utile de saisir les mots de passe pour les personnes sur le service que d'avoir RCE sur leur serveur, bien sûr.
Sur le serveur: performances améliorées s'il n'a pas à exécuter bcrypt sur chaque mot de passe entrant, ce qui décharge certains coûts de calcul sur le client sans introduire de nouvelles vulnérabilités. Cela semble être une bonne chose pour l'administrateur de votre serveur ainsi que vos coûts matériels.
Pourtant, il semble que la meilleure pratique serait d'incorporer le hachage de mot de passe dans le côté client, sauf s'il crée des temps de chargement de page insupportables pour les utilisateurs.
J'accepte que si SSL/TLS est disponible, l'avantage du hachage côté client pour protéger le processus d'authentification est limité. Cependant, SSL/TLS ne résout pas la vulnérabilité aux attaques matérielles personnalisées si l'attaquant a accès aux hachages stockés (APRÈS le processus). Les fonctions telles que les hachages salés simples ou les schémas comme PBKDF2 sont très vulnérables à ces attaques en raison de leurs faibles besoins en mémoire. Le craquage de mots de passe, protégés par ces schémas, est rapide et bon marché. Et c'est au moins l'un des principaux problèmes de hachage de mot de passe.
À première vue, cela n'a rien à voir avec le hachage côté client par rapport à SSL/TLS - mais: lorsqu'un serveur implémente un schéma de hachage de mot de passe en mémoire dur tel que Scrypt, Argon2 ou Catena pour protéger les attaques matérielles personnalisées, le matériel du serveur les besoins augmentent considérablement. En réalité, les services réduisent donc la dureté de la mémoire ou basculent vers des schémas vulnérables. Le hachage côté client aide un peu à contourner ce problème. Lorsque les clients calculent ces fonctions coûteuses (en mémoire dure), le service peut les utiliser sans avoir besoin d'un meilleur matériel.
Les schémas de hachage de mot de passe modernes offrent donc la possibilité de déléguer les parties les plus chères (en mémoire) de la fonction au client. Cette fonctionnalité est appelée secours du serveur et est proposée par Argon2 et Catena.
Conclusion: L'utilisation de schémas de hachage de mot de passe modernes, qui sont beaucoup moins vulnérables aux attaques matérielles personnalisées, augmentera ou du moins devrait augmenter l'utilisation du hachage côté client à l'avenir - bien sûr avec SSL/TLS.