Hachage de mot de passe côté client

Question

Edit: mis à jour pour mettre davantage l'accent sur l'objectif - tranquillité d'esprit pour l'utilisateur, et non pas renforcer la sécurité.

Après avoir lu quelques discussions ici sur le hachage côté client des mots de passe, je me demande toujours s'il ne serait pas correct de l'utiliser dans une situation particulière.

Plus précisément, j'aimerais que le client - un Java - hache son mot de passe en utilisant quelque chose comme PBKDF2, en utilisant comme sel une combinaison de son adresse e-mail et d'un constant octet spécifique à l'application . L'idée étant que le hachage est reproductible pour l'authentification, mais il est à espérer qu'il n'est pas vulnérable aux attaques de rétro-ingénierie (pour découvrir le mot de passe littéral) autre que la force brute si le les données du serveur sont compromises.

Objectif:

Le hachage côté client est pour la tranquillité d'esprit de l'utilisateur que son mot de passe littéral n'est jamais reçu par le serveur, même s'il a l'assurance de le hacher de toute façon. Un autre avantage secondaire (ou peut-être un passif?) Est que le coût de hachage d'un PBKDF2 itéré ou similaire incombe au client.

Les caractéristiques de l'environnement sont:

Toutes les communications client-serveur sont cryptées.
Les messages rejoués ne sont pas autorisés. c'est à dire. le hachage envoyé par le client ne peut pas être utilisé efficacement comme mot de passe par une écoute indiscrète.
Les adresses IP d'interdiction temporaire et de mise sur liste noire sont possibles pour plusieurs tentatives de connexion infructueuses dans un court laps de temps. Cela peut être par compte d'utilisateur ou à l'échelle du système.

Préoccupations:

"Évitez de concevoir des schémas d'authentification faits maison."
Le sel est déterministe pour chaque utilisateur, même si les hachages produits seront spécifiques à cette application en raison des octets supplémentaires (identiques) jetés dans le sel. Est-ce mauvais?
Les authentifications sur le serveur se feront sans retard significatif, sans coût de hachage. Est-ce que cela augmente la vulnérabilité aux attaques d'authentification par force brute distribuée?
Les clients voyous peuvent fournir un hachage faible pour leurs propres comptes. En fait, pas trop inquiet à ce sujet.
Le serveur doit-il ressasser le hachage du client avant de le stocker?

Pensées?

David Wachtfogel · Accepted Answer

Le hachage côté client ne résout pas le problème principal que le hachage de mot de passe est censé 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 usurper l'identité de tous les utilisateurs en envoyant au serveur les mots de passe hachés de la base de données tels quels.

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

Une solution possible pour cela consiste à hacher à la fois côté client et côté serveur. Vous pouvez toujours décharger la lourde opération PBKDF2 vers le client et effectuer une seule opération de hachage (côté client, le mot de passe haché PBKDF2) 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.

Motoma · Answer

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:

Évitez également les suggestions non validées sur la cryptographie que vous trouvez sur Internet. (Avertissement: je ne suis pas Bruce Schneier.)
Les sels déterministes ne sont pas un problème - la seule vraie exigence du sel est qu'il est unique pour chaque utilisateur. Le véritable objectif du sel est d'empêcher une force brute sur un mot de passe de se transformer 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.
Comme je l'ai mentionné ci-dessus, PBKDF2 est agréable car vous pouvez décider arbitrairement de la difficulté de calcul du hachage. Vous pouvez sélectionner un c de telle sorte qu'un seul hachage sur du matériel moderne ne prenne que quelques secondes, éliminant ainsi efficacement le risque d'attaque par force brute au niveau de l'API. (Bien sûr, votre client pourrait ne pas bénéficier d'un délai aussi long à la connexion.)
Un utilisateur peut choisir des mots de passe simples - il ne se fait que du mal. Si vous vouliez éliminer ce risque, vous feriez en sorte que le serveur génère le hachage la première fois, à condition que le mot de passe passe par un canal crypté.
Oui, et vous devrez également les saler uniquement. 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 ouvrez à un vecteur d'attaque par déni de service épuisant CPU - un attaquant spams simplement des tentatives d'authentification de mot de passe vides sur Tor, mots de passe que votre serveur doit essayer de hacher avant de savoir qu'ils sont frauduleux, vous laissant éventuellement avec un serveur débordé ..

ddyer · Answer

Si vous hachez le mot de passe côté client, quel que soit le résultat IS le mot de passe, vous n'obtiendrez aucune sécurité réelle. 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 zéro, où un échange de messages prouve que le client connaît le vrai mot de passe, sans le transmettre réellement.

Stephen Touset · Answer

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 antécédents pour le faire de manière sécurisée. Je recommande fortement 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 quelque chose appelé "attaque de rétro-ingénierie" qui n'a pas de véritable définition ou signification.

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 gardés secrets. Vous pouvez (et devez) 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 fixes spécifiques à l'application sont parfois appelés "poivrons", et je ne connais aucune littérature cryptographique qui soutienne ou encourage leur utilisation.

Troisièmement, PBKDF2 est correct, mais sérieusement juste tilisez BCrypt . BCrypt a été conçu pour cela et est largement utilisé. De bonnes implémentations BCrypt géreront la génération de sel et l'étalonnage/détection automatique des facteurs 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 pour s'authentifier. Cependant, il est apparemment difficile à 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é réelle du problème.

Pour faire court: 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.

Thomas Pornin · Answer

Le hachage du 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'entre elles. Je suis tout à fait pour que les utilisateurs soient dans un état d'esprit harmonieux et en harmonie avec l'Univers, mais je trouve douteuse l'idée de promouvoir un moyen d'induire aux utilisateurs de réutiliser le même mot de passe sur plusieurs sites.

Un bon cas pour le hachage côté client est la façon dont certains "coffres-forts de mot de passe" fonctionnent: 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 facilité d'utilisation de toujours utiliser le même mot de passe partout, tout en ne donnant pas réellement votre mot de passe principal à des dizaines de sites distincts. Mais cela ne fonctionne que tant que l'algorithme de dérivation de 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 afin d'utiliser des applets qui utilisent 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 lorsqu'un hachage lent est utilisé (afin de rendre le craquage de mot de passe plus difficile pour un attaquant qui pourrait récupérer une copie de la base de données des mots de passe hachés); il est tentant de décharger le coût sur le client, car, lorsque le client veut se connecter, il est surtout 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 les smartphones bon marché ou les ordinateurs de dix ans). C'est comme ramasser 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, est de 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 pour 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 de manière aléatoire.)

goodguys_activate · Answer

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

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

et ce lien sur l'authentification forte de l'utilisateur http://www.browserauth.net/strong-user-authentication

::Mise à jour

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

Luc · Answer

L'objectif principal du hachage de mot de passe est d'empêcher quiconque, sauf l'utilisateur, d'apprendre le mot de passe. Les gens les réutilisent et ils ne sont généralement pas super forts s'ils sont mémorisés. C'est pourquoi nous nous soucions des hachages lents (PBKDF2, Bcrypt, Scrypt, Argon2, peu importe) 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 d'avoir le hachage du serveur quoi qu'il arrive 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 ils ont trouvé (ils doivent d'abord les casser).

Nous voulons conserver les deux avantages. À cette fin, je soutiens que nous devrions hacher sur le serveur et le client.

Pourquoi sur le serveur?
. .

Pourquoi sur le client?

Transparence
Chaque fois qu'une entreprise est piratée, nous devons espérer qu'ils nous disent comment les mots de passe ont été hachés, le cas échéant. 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 se fait et empêcher des 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: les `` hackers éthiques '' ou les hackers à chapeau blanc le font.
Détection de compromis
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 le texte en clair de toute façon". Cet argument n'est valable que pour les sites Web, mais les gens omettent généralement de le mentionner, ce qui fait que personne ne hache côté client dans les applications non plus. 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 gens qui scanneront les sites Web importants pour voir si le hachage est toujours là (ce serait tout à fait un indicateur de compromis si Paypal supprime hachage côté client (dans le cas hypothétique où ils feraient du 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 en cas de suppression, tout comme nous vous avertissons pour la connexion formulaires sur les pages http.
Améliorez le standard
Maintenant que nous pouvons voir la mise en œuvre de tout le monde, il y aura un débat sur qui a obtenu le plus longtemps et qui a obtenu le meilleur. Cette discussion fait certainement pression sur les mauvais pour qu'ils fassent mieux, et elle aboutit probablement aussi à la normalisation. Ce serait vraiment bien si vous pouviez simplement ajouter un paramètre à l'élément d'entrée de mot de passe, comme <input type=password hash=v1>, qui ferait tout le hachage pour vous (il serait salé avec le champ nom de domaine et nom d'utilisateur, mais tous ces détails de cette proposition dépassent le cadre de cette réponse).
Décharger le serveur
Un risque de hachage très lent sur le serveur est qu'un attaquant peut 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 à essayer de prendre vers le bas. En faisant le hachage lent sur le client (dont le processeur est inutilisé 99% du temps de toute façon, et ce n'est pas comme si la plupart des gens se connectent à 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.
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 point de terminaison TLS ou en installant du code supplémentaire). Il y a suffisamment d'histoires d'employés aigres, ou même d'adolescents créant des applications qui pourraient penser que c'est drôle de regarder les mots de passe de leurs utilisateurs (j'en faisais partie, il y a longtemps).
Aucun e-mail en texte brut
Si le serveur n'a pas votre mot de passe, il ne peut pas vous envoyer d'e-mail du type "Merci de votre inscription, votre nom d'utilisateur et votre mot de passe sont xxx". Le courrier électronique est généralement considéré comme non sécurisé, mais il existe encore des sites Web qui le font.
Pas d'exposition accidentelle
Un incident s'est produit récemment, où des mots de passe ont été accidentellement écrits dans des fichiers journaux. Je ne mentionnerai pas le nom de l'entreprise parce que 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. De tels accidents se produisent tout simplement. Il existe également une exposition dans de nombreux réseaux où un système distinct effectue la terminaison TLS et envoie ensuite le texte en clair de la demande à d'autres systèmes, permettant à n'importe quelle boîte réseau de voir les mots de passe (Google le faisait jusqu'à ce qu'ils aient vent du NSA ayant des interceptions dans leur réseau interne). Ce serait beaucoup moins un problème (il y aurait beaucoup moins d'exposition) si nous faisions du hachage côté client.
Réduisez l'impact de la transmission compromise
Si le canal de transmission sécurisé échoue pour une raison quelconque, par exemple un bogue dans TLS, 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écrypter un flux crypté des années plus tard, par exemple parce que RC4 est maintenant connu pour être cassé il y a plus de quelques années.
Pourquoi pas?
Je ne vois aucune raison pour laquelle vous devriez pas le faire, en supposant que vous fassiez également 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, ce serait quand même une amélioration.

[~ # ~] faq [~ # ~]

Je pense que la seule raison pour laquelle le hachage côté client n'est pas la norme, c'est parce que personne d'autre ne le fait. Chaque fois que quelqu'un le propose, tout le monde pense "alors pourquoi ne le faisons-nous pas déjà? Il doit y avoir une raison!" et commencer à remettre en question les avantages, ou inventer des raisons illogiques. Si les raisons ci-dessus ne suffisent pas déjà, permettez-moi d'essayer de réfuter certaines des questions que j'ai entendues auparavant:

"Mais un attaquant supprimerait simplement le code responsable du hachage!" Cela ne s'applique qu'aux applications Web. Les applications normales (parmi lesquelles les applications mobiles) n'ont 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 construirions des vérifications pour cela: les gens créeront des extensions de navigateur et scanneront les sites Web pour voir si le hachage est toujours là, et pourront sonner l'alarme s'il a soudainement disparu. Il pourrait également y avoir une normalisation. Tous des points ci-dessus sont toujours valables, même dans le cas d'une application web.
"Mais quel que soit le résultat [du hachage côté client] IS le mot de passe!" Laissez-moi vous poser une question: si votre base de données de connexion est compromise, pensez-vous vraiment l'attaquant doit toujours 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 en plus une hachage rapide sur le serveur.
"Mais vous devez simplement utiliser un gestionnaire de mots de passe au lieu de compter sur la sécurité des hachages!" Je suis d'accord, ce serait idéal. Authentification à deux facteurs partout, utilisée par tout le monde, avec les gestionnaires de mots de passe et les cartes à puce ... oui, ce jour-là, nous n'avons plus besoin du 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.
"Mais vous ne devez 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 sera toujours en mesure de gâcher toute sécurité que vous implémentez, s'il le souhaite.
"Mais comment allez-vous saler le hachage?" Le champ du nom d'utilisateur. Un sel n'est pas secret, seulement unique, tout comme votre champ de nom d'utilisateur.