Dois-je hacher le mot de passe avant de l'envoyer côté serveur?

110

J'ai remarqué que la plupart des sites envoient les mots de passe sous forme de texte brut via HTTPS au serveur. Y a-t-il un avantage si au lieu de cela j'ai envoyé le hachage du mot de passe au serveur? Serait-ce plus sûr?

Jader Dias
la source
5
@Jader Dias: Je sais que vous ne l'avez pas demandé, mais cela ne serait pas plus sûr si vous le hachiez, ALORS envoyez-le via https. En fait, cela pourrait le rendre moins sûr, car vous exposez votre sel. De plus, (en parlant de mon dos ici), le mélange d'algorithmes pourrait provoquer plus de collisions de hachage et le rendre plus piratable.
Merlyn Morgan-Graham
@Merlyn "collisions de hachage" bon point!
Jader Dias
Le mélange d'algorithmes n'augmente pas du tout la probabilité de collision. C'est tout l'intérêt d'une fonction de hachage. Étant donné toute entropie d'entrée, renvoie une sortie qui a une probabilité égale d'être n'importe où dans l'espace de sortie possible.
JJ
@JJ "Le mélange d'algorithmes n'augmente pas du tout la probabilité de collision." J'aimerais vraiment voir une preuve de cette affirmation. Permettez-moi de vous arrêter: c'est faux , en général cela augmente les collisions. Je peux facilement construire une fonction de hachage telle que h (x) n'est pas constant à 0 mais h (h (x)) = 0 pour tout x. Vous devrez donc vous référer à l'ensemble exact d'algorithmes de hachage et à la façon dont vous les mélangez. Ensuite, vous devrez prouver votre déclaration. AFAIK même pour plusieurs SHA (avec du sel), c'est un problème ouvert. Et fondamentalement, nous pensons que c'est vrai. La cryptographie est difficile.
freakish

Réponses:

155

C'est une vieille question, mais j'ai ressenti le besoin de donner mon avis sur cette question importante. Il y a tellement de désinformation ici

L'OP n'a jamais mentionné l'envoi du mot de passe en clair via HTTP - uniquement HTTPS, mais beaucoup semblent répondre à la question de l'envoi d'un mot de passe via HTTP pour une raison quelconque. Cela dit:

Je crois que les mots de passe ne devraient jamais être conservés (et encore moins transmis) en texte brut. Cela signifie non conservé sur le disque, ni même en mémoire.

Les personnes qui ont répondu ici semblent penser que HTTPS est une solution miracle, ce qui n'est pas le cas. Cela aide certainement grandement et devrait être utilisé dans toute session authentifiée.

Il n'est vraiment pas nécessaire de savoir ce qu'est un mot de passe original. Tout ce qui est requis est un moyen fiable pour générer (et re-générer de manière fiable) une "clé" d'authentification basée sur le texte d'origine choisi par l'utilisateur. Dans un monde idéal, ce texte devrait générer immédiatement une "clé" en la hachant avec du sel irréversible. Ce sel doit être unique pour les informations d'identification de l'utilisateur générées. Cette «clé» sera ce que vos systèmes utilisent comme mot de passe. De cette façon, si vos systèmes sont compromis à l'avenir, ces informations d'identification ne seront jamais utiles que contre votre propre organisation, et nulle part ailleurs où l'utilisateur a été paresseux et a utilisé le même mot de passe.

Nous avons donc une clé. Nous devons maintenant nettoyer toute trace du mot de passe sur le périphérique client.

Ensuite, nous devons obtenir cette clé pour vos systèmes. Vous ne devez jamais transmettre une clé ou un mot de passe "en clair". Pas même sur HTTPS. HTTPS n'est pas impénétrable. En fait, de nombreuses organisations peuvent devenir un MITM de confiance - non pas du point de vue des attaques, mais pour effectuer des inspections sur le trafic afin de mettre en œuvre leurs propres politiques de sécurité. Cela affaiblit HTTPS, et ce n'est pas la seule façon dont cela se produit (comme les redirections vers des attaques HTTP MITM par exemple). Ne présumez jamais qu'il est sécurisé.

Pour contourner ce problème, nous hachons la clé avec un nonce unique. Ce nonce est unique pour chaque soumission d'une clé à vos systèmes - même pour les mêmes informations d'identification au cours de la même session si vous devez l'envoyer plusieurs fois. Vous pouvez inverser ce nonce une fois qu'il arrive dans vos propres systèmes pour récupérer la clé d'authentification et authentifier la demande.

À ce stade, je le hacherais de manière irréversible une dernière fois avant qu'il ne soit stocké de manière permanente dans vos propres systèmes. De cette façon, vous pouvez partager le sel des informations d'identification avec des organisations partenaires à des fins de SSO et autres, tout en étant en mesure de prouver que votre propre organisation ne peut pas usurper l'identité de l'utilisateur. La meilleure partie de cette approche est que vous ne partagez jamais rien généré par l'utilisateur sans son autorisation.

Faites plus de recherches, car il y a plus que ce que j'ai divulgué, mais si vous voulez fournir une véritable sécurité à vos utilisateurs, je pense que cette méthode est actuellement la réponse la plus complète ici.

TL; DR:

Utilisez HTTPS. Hachez les mots de passe en toute sécurité, de manière irréversible, avec un sel unique par mot de passe. Faites cela sur le client - ne transmettez pas leur mot de passe réel. La transmission du mot de passe d'origine des utilisateurs à vos serveurs n'est jamais "OK" ou "Fine". Nettoyez toute trace du mot de passe d'origine. Utilisez un nonce indépendamment de HTTP / HTTPS. C'est beaucoup plus sûr à plusieurs niveaux. (Réponse à OP).

user3299591
la source
25
Je viens de vérifier gmail et facebook - les outils de développement Chrome me disent à la fois POST avec un message urlencodé contenant mon nom d'utilisateur et mon mot de passe en texte brut (non salé). Comment / pourquoi les grands acteurs n'utilisent-ils pas le salage nonce sur le client?
gremwell
18
Vous hachez la clé avec un nonce et prétendez pouvoir inverser le nonce côté serveur. Est-ce que vous forcez brutalement le hachage alors? Ou comment récupérer un nonce lorsque vous obtenez un hash = HASH (secret + nonce) HASH devrait être une fonction irréversible. L'avez-vous mis en œuvre? Je ne pense pas que ce que vous expliquez soit réalisable. Pouvez-vous créer un organigramme du protocole?
Argent
19
Si vous ne faites pas confiance à HTTPS, chaque effort est inutile! Votre code lui-même est expédié par le biais du fil et un attaquant peut modifier / remplacer toutes vos tentatives pour sécuriser le mot de passe en transit
Sajid Kalla
3
Un MitM qui peut réécrire un certificat peut réécrire le nonce. Ou ce que Sajid a dit.
leewz
4
Si vous vous inquiétez de MITM avec HTTPS, quel est l'intérêt d'envoyer un sel au client afin que le client puisse saler le mot de passe avant de transmettre le hachage au serveur? Cela semble inutile. Autant faire un hachage non salé sur le serveur, puis utiliser un sel pour hacher à nouveau sur le serveur. Clairement, le client ne peut pas non plus être le générateur du client-salt car à la prochaine connexion, il serait différent et ne calculerait pas le même hachage côté serveur.
écraser le
24

Puisqu'il s'agit de HTTPS, il est tout à fait correct d'envoyer le mot de passe sans hachage (sur HTTPS, ce n'est pas du texte en clair). De plus, si votre application dépend de HTTPS pour sécuriser son contenu, alors il est inutile de hacher le mot de passe avant de l'envoyer via HTTPS (c'est-à-dire si un attaquant peut déchiffrer les données sur le fil, vous êtes quand même foutu)

Kiersten Arnold
la source
5
Cela ne devrait pas être un problème. Si le client utilise un proxy, le proxy verra uniquement les données cryptées HTTPS. Si vous parlez d'une attaque man-in-the-middle, un certificat correctement configuré devrait empêcher cela.
Kiersten Arnold
7
@Jader: Aucune manipulation des données n'arrêtera une attaque MITM, car elle peut simplement relayer tout ce qui lui arrive. Peu importe que vous transmettiez un mot de passe ou un hachage. C'est une question complètement différente.
David Thornley
2
Le but de SSL (HTTPS = HTTP sur SSL) est de contrecarrer MITM.
yfeldblum
1
@carnold - MINTM - Et la redirection vers http? La plupart des gens le remarqueraient-ils? sslstrip - securityfocus.com/brief/910
nate c
1
@Jader Dias vous essayez d'arrêter un problème qui n'existe pas. HTTPS arrête ce problème, un hachage côté client n'ajoute aucun niveau de sécurité. On ne peut jamais faire confiance au client.
Tour
17

Non, en fait ce serait une vulnérabilité. Si l'attaquant parvient à obtenir le hachage de la base de données, il pourrait alors l'utiliser pour s'authentifier sans avoir besoin de le casser. En aucun cas, un utilisateur ou un attaquant ne doit pouvoir obtenir un mot de passe de hachage.

L'intérêt du hachage des mots de passe est d'ajouter une couche de sécurité supplémentaire. Si un attaquant est capable d'obtenir le hachage et le sel de la base de données en utilisant SQL Injection ou une sauvegarde non sécurisée, il doit trouver le texte brut en le forçant brutalement. John The Ripper est couramment utilisé pour casser les hachages de mots de passe salés.

Ne pas utiliser https est une violation du Top 10 de l'OWASP: A9-Insufficient Transport Layer Protection

EDIT: Si dans votre implémentation vous calculez a sha256(client_salt+plain_text_password)puis calculez un autre hachage côté serveur, sha256(server_salt+client_hash)ce n'est pas une vulnérabilité sérieuse. Cependant, il est toujours susceptible d'écouter et de rejouer la demande. Il s'agit donc toujours d'une violation flagrante de WASP A9. Cependant, cela utilise toujours un résumé de message comme couche de sécurité.

La chose la plus proche que j'ai vue d'un remplacement côté client pour https est un diffie-hellman dans l'échange de clés en javascript . Cependant, cela empêche les attaques MITM actives et constitue donc jusqu'à la technicité une violation de OWASP A9. Les auteurs du code conviennent que ce n'est pas un remplacement complet pour HTTPS, mais c'est mieux que rien et mieux qu'un système de hachage côté client.

tour
la source
4
En fait, je le hacherais à nouveau sur le serveur, veuillez donc modifier votre réponse en envisageant ce scénario.
Jader Dias
@Rook utilise l'échange de clés diffie-hellman avec https est une solution "inutile"? (Je veux dire que nous ne pouvons utiliser que https et diffie helman n'augmente pas la sécurité imao)
Michel Gokan
@Michel Kogan, un échange de clés DH peut être utilisé dans HTTP avec d'autres outils.
tour
1
@Rook C'est une bonne pratique d'appliquer un hachage sur le serveur, donc je pense que vous devriez mettre à jour le début de votre réponse pour ne pas rejeter le hachage côté client, et mentionner seulement ensuite que les hachages et sels stockés sur le serveur ne devraient jamais être exposés.
Levente Pánczél
8

L'envoi d'un hachage sur le fil va complètement à l'encontre de l'objectif du hachage, car un attaquant peut simplement envoyer le hachage et oublier le mot de passe. En un mot, un système qui s'authentifie à l'aide d'un hachage en texte clair est grand ouvert et peut être compromis avec rien de plus que le reniflage du réseau.

Paul Keister
la source
2
Cela semble une connerie totale ... Comment un hachage est-il moins sécurisé qu'un mot de passe?
Levente Pánczél
1
Ceci n'est vrai que pour les hachages «stupides». Considérez ceci: un serveur envoie un salt S au client et le client fait HASH (S + PASSWORD), et l'envoie au serveur. Le serveur n'honore ce hachage spécifique que pour la session en cours. Un attaquant peut en effet envoyer le hachage et oublier le mot de passe, mais UNIQUEMENT POUR LA SESSION EN COURS. C'est donc plus sûr que le texte brut.
Hello World
Mise à jour: l'authentification Digest Access est encore plus sophistiquée: en.wikipedia.org/wiki/Digest_access_authentication
Hello World
2
Juste pour être clair: quand je dis "va à l'encontre de l'objectif du hachage", je fais référence à une pratique courante et sécurisée de hachage des mots de passe avant de les stocker dans une base de données. Néanmoins, l'argument soutient que l'envoi d'une valeur hachée au lieu d'un mot de passe ne fait rien pour améliorer la sécurité sans étapes supplémentaires.
Paul Keister du
Juste pour ajouter à ce que Paul a dit: ce type d'attaque est appelé une «attaque de relecture» si quelqu'un veut en savoir plus ailleurs.
5

Le mot de passe en clair ne jamais (même pas lors de l'utilisation de HTTPS) quitter le client. Il doit être haché de manière irréversible avant de quitter le client car il n'est pas nécessaire que le serveur connaisse le mot de passe réel.

Le hachage puis la transmission résout les problèmes de sécurité pour les utilisateurs paresseux qui utilisent le même mot de passe à plusieurs endroits (je sais que je le fais). Cependant, cela ne protège pas votre application en tant que pirate informatique qui a accédé à la base de données (ou a pu de toute autre manière mettre la main sur le hachage) car le pirate pourrait simplement transmettre le hachage et le faire accepter par le serveur.

Pour résoudre ce problème, vous pouvez bien sûr simplement hacher le hachage reçu par le serveur et l'appeler un jour.

Mon approche du problème dans une application Web basée sur socket que je crée est que lors de la connexion au client, le serveur génère un sel (chaîne aléatoire à ajouter avant le hachage) et le stocke sur la variable sockets, puis il transmet ce hachage au client. Le client prend le mot de passe de l'utilisateur, le hache, ajoute le sel du serveur et hache le tout, avant de le transmettre au serveur. Ensuite, il est envoyé au serveur qui compare ce hachage au hachage (hachage dans le DB + salt). Pour autant que je sache, c'est une bonne approche, mais pour être honnête, je n'ai pas beaucoup lu sur le sujet et si je me trompe sur quelque chose, j'aimerais être corrigé :)

Victor Zimmer
la source
3

Utilisez HTTP Digest - il sécurise le mot de passe même sur http (mais la meilleure utilisation serait un condensé http sur https)

Wikipédia:

L'authentification d'accès HTTP Digest est l'une des méthodes convenues qu'un serveur Web peut utiliser pour négocier les informations d'identification avec un utilisateur Web (à l'aide du protocole HTTP). L'authentification Digest est destinée à remplacer l'utilisation non cryptée de l'authentification d'accès de base, permettant d'établir l'identité de l'utilisateur en toute sécurité sans avoir à envoyer un mot de passe en texte clair sur le réseau. L'authentification Digest est essentiellement une application de hachage cryptographique MD5 avec l'utilisation de valeurs nonce pour empêcher la cryptanalyse.

Lien: http://en.wikipedia.org/wiki/Digest_access_authentication

Si vous voulez voir une utilisation "réelle", vous pouvez regarder phpMyID - un fournisseur php openid qui utilise l'authentification http digest http://siege.org/phpmyid.php

.. ou vous pouvez commencer à partir des exemples d'authentification php à l'adresse http://php.net/manual/en/features.http-auth.php

Http digest rfc: http://www.faqs.org/rfcs/rfc2617

D'après mes tests, tous les navigateurs modernes le supportent ...

vlad b.
la source
HTTP Digest implémente ce que je voulais dire dans cette question, mais aurions-nous un avantage si nous utilisions HTTPS Digest (SSL + HTTP Digest)?
Jader Dias
Une différence principale serait que tout est envoyé / reçu crypté - les en-têtes http envoyés et reçus et la réponse html. Pour quelqu'un essayant au hasard de "pirater" ssl en utilisant une attaque de type "man-in-the-middle", le condensé http serait un motif supplémentaire pour lui faire rechercher une autre cible plus facile, ou s'il enregistre tout le trafic capturé, vos mots de passe sont toujours plus sûrs. J'ai peut-être mal compris la question, l'anglais n'est pas ma langue maternelle.
vlad b.
Le hachage du mot de passe présente un gros avantage: si le trafic est enregistré ou capturé, cela rendra le travail plus difficile pour cette personne. De plus, avec http digest, si ssl n'est pas toujours requis, vous pouvez laisser les utilisateurs choisir entre http et https. Ou vous pouvez utiliser différents protocoles pour différents serveurs (par exemple, je ne force pas https pour afficher / modifier moins de données importées (nom d'utilisateur, téléchargement d'avatar) mais appliquer https sur la facturation et d'autres parties du site (de cette façon, je peux réduire la charge sur certains serveurs, si / en cas de besoin).
. vlad b
3

Si vous cherchez à remplacer un mot de passe en texte clair sur HTTPS par un mot de passe haché sur HTTP, vous demandez des problèmes. HTTPS génère une clé de transaction partagée aléatoire lors de l'ouverture d'un canal de communication. C'est difficile à craquer, car vous êtes à peu près limité au forçage brutal de la clé partagée utilisée pour une transaction (relativement) à court terme. Alors que votre hachage peut être simplement reniflé, mis hors ligne et recherché dans une table arc-en-ciel ou simplement forcé sur une longue période de temps.

Cependant, une obfuscation de mot de passe de base côté client (pas de hachage) envoyée via HTTPS a une certaine valeur. Si je ne me trompe pas, cette technique est en fait utilisée par certaines banques. Le but de cette technique n'est pas de protéger le mot de passe contre le reniflement sur le fil. Il s'agit plutôt d'empêcher le mot de passe d'être utilisable pour des outils d'espionnage stupides et des plug-ins de navigateur qui saisissent simplement chaque requête HTTPS GET / POST qu'ils voient. J'ai vu un fichier journal capturé à partir d'un site Web malveillant contenant 400 Mo de transactions GET / POST aléatoires capturées à partir de sessions utilisateur. Vous pouvez imaginer que les sites Web qui n'utilisaient que HTTPS apparaîtront avec des mots de passe en texte clair dans le journal, mais que les sites Web avec une obfuscation très basique (ROT13) apparaîtront également avec des mots de passe qui ne sont pas immédiatement utiles.

Simon chez LabSlice-com
la source
"mais les sites Web avec une obfuscation très basique (ROT13) s'afficheraient également avec des mots de passe qui ne sont pas immédiatement utilisés" - cela contredit la déclaration originale. La clé est qu'ils ne sont pas IMMÉDIATEMENT utilisables, mais c'est vraiment futile. Le mot de passe et son ROT13 sont équivalents. MAIS si vous SHA2 le mot de passe, il ne sera pas présent dans les journaux (de sorte que vos administrateurs ne connaissent pas les mots de passe possibles des utilisateurs vers d'autres systèmes), et vous n'êtes PLUS en violation de presque toutes les lois sur la confidentialité.
Levente Pánczél
2

Si vous êtes connecté à un serveur https, le flux de données entre le serveur et le navigateur doit être chiffré. Les données sont uniquement du texte brut avant d'être envoyées et après avoir été reçues. Article Wikipédia

Jac
la source
Les mandataires n'interceptent-ils pas ces données?
Jader Dias
Si je comprends bien, ils le font, mais le proxy n'est pas responsable du cryptage / décryptage et à moins qu'il ne s'agisse d'un proxy sans scrupules ne transmet que les données. Le type et la force de cryptage dépendent de ce que le serveur et le client peuvent tous deux prendre en charge.
jac
1
Même si le proxy n'est pas anxieux, il ne peut pas décrypter les données car il est crypté à l'aide de la clé publique du serveur. La seule façon pour un proxy de déchiffrer les données est d'usurper le certificat du serveur avec une clé différente
Kiersten Arnold
@ Jader. S'ils le faisaient, cela rendrait HTTPS assez boiteux. lorsque vous vous authentifiez auprès d'un serveur avec HTTPS, vous obtenez une garantie (en supposant que le certificat est valide) que vous vous connectez à un certain serveur et que vous disposez d'un chemin crypté d'un bout à l'autre. En théorie, une attaque d'homme au milieu pourrait bien sûr être faite pour vous tromper, mais ce n'est pas la même chose qu'un proxy Web de base.
Peter Recore
2

Avis de non-responsabilité: je ne suis pas du tout un expert en sécurité - et je publie avec l' espoir que d'autres critiqueront ma position comme étant trop prudente ou améliorable et j'en tirerai des leçons. Cela dit, je tiens simplement à souligner que le hachage lorsqu'il quitte votre client ne signifie pas que vous n'avez pas à hacher le backend avant de le mettre dans la base de données.

Faire les deux

Faites les deux parce que:

  1. Le hachage pendant le trajet permet de couvrir les vulnérabilités du transport, si la connexion SSL est compromise, ils ne peuvent toujours pas voir le mot de passe brut. Cela n'aura pas d'importance en termes de pouvoir se faire passer pour des utilisateurs autorisés, mais cela protégera vos utilisateurs contre la lecture de leurs mots de passe en association avec leur e-mail. La plupart des gens ne suivent pas les meilleures pratiques et utilisent le même mot de passe pour plusieurs de leurs comptes, ce qui peut constituer une vulnérabilité sérieuse pour vos visiteurs.

  2. Si quelqu'un, d'une manière ou d'une autre, était capable de lire les mots de passe de la base de données (cela se produit, pensez à l'injection SQL), il ne sera toujours pas en mesure d'exécuter des actions privilégiées en se faisant passer pour des utilisateurs via mon API. Ceci est dû à l'asymétrie de hachage; même s'ils connaissent le hachage stocké dans votre base de données, ils ne connaîtront pas la clé d'origine utilisée pour le créer et c'est ce que votre middleware d'authentification utilise pour s'authentifier. C'est également pourquoi vous devez toujours saler votre stockage de hachage.

Certes, ils pourraient faire beaucoup d'autres dégâts s'ils avaient libre cours pour lire ce qu'ils veulent dans votre base de données.

Je veux juste souligner ici que si vous décidez de hacher la clé avant de quitter vos clients, cela ne suffit pas - le hachage du backend est, à mon avis, beaucoup plus important et voici pourquoi: si quelqu'un intercepte le trafic de votre client, puis ils verront le contenu du passwordchamp. Qu'il s'agisse d'un hachage ou d'un texte brut, cela n'a pas d'importance - ils peuvent le copier textuellement pour se faire passer pour un client autorisé. (Sauf si vous suivez les étapes décrites par @ user3299591, et je vous recommande de le faire). Le hachage de la colonne DB, en revanche, est une nécessité et pas du tout difficile à mettre en œuvre.

pixelpax
la source
0

Il serait en fait moins sûr de hacher le mot de passe et de l'envoyer sur un canal non chiffré. Vous exposerez votre algorithme de hachage sur le client. Les pirates pourraient simplement renifler le hachage du mot de passe, puis l'utiliser pour pirater plus tard.

En utilisant HTTPS, vous empêchez un hacker d'obtenir le mot de passe d'une source unique, car HTTPS utilise deux canaux, tous deux cryptés.

Carter Medlin
la source
1
En fait, je le hacherais à nouveau sur le serveur, et j'utiliserais de toute façon HTTPS, alors veuillez modifier votre réponse en envisageant ce scénario.
Jader Dias
@Jader, le fait est que tout ce dont un attaquant a besoin maintenant, c'est du premier hachage, plutôt que d'un mot de passe. En effet, le hachage que vous prenez du mot de passe côté client est désormais aussi utile que le mot de passe lui-même. Vous ne gagnez donc pas vraiment beaucoup de sécurité.
Peter Recore
quelqu'un a-t-il déjà pensé à ne pas envoyer des parties du jeton? comme si vous connaissez vos méthodes de hachage, pourquoi enverriez-vous cela. le serveur ne devrait-il pas connaître la clé client à déchiffrer?
jemiloii
0

La question de savoir s'il y a un avantage et s'il est plus (ou moins) sécurisé dépend vraiment de la mise en œuvre. Il y a sans doute un avantage, mais si vous l'implémentez mal, vous pouvez certainement créer une solution moins sécurisée que de passer même un mot de passe en texte clair.

Cela peut être envisagé du point de vue de deux types d'attaques: une avec accès au trafic réseau et une autre avec accès à la base de données.

Si votre attaquant peut intercepter la version en texte brut du trafic réseau, il est plus sûr de voir un hachage du mot de passe que de voir le mot de passe en texte clair. Bien que l'attaquant puisse toujours se connecter à votre serveur en utilisant ce hachage, il faudrait une fissure par force brute (parfois pré-calculée) de ce hachage pour déterminer le mot de passe qui pourrait être utile sur d'autres systèmes. Les gens devraient utiliser des mots de passe différents sur différents systèmes, mais souvent pas.

Si un attaquant a accédé à la base de données, peut-être via une copie d'une sauvegarde, vous voudrez vous assurer que l'on ne peut pas se connecter avec seulement ces connaissances. Si, par exemple, vous avez stocké un hachage salé avec le nom de connexion en tant que hash(login_name+password), et que vous avez transmis le même hachage du client pour une comparaison directe, alors l'attaquant pourrait choisir un utilisateur au hasard, envoyer le hachage lu à partir de la base de données et se connecter en tant que cet utilisateur sans connaître le mot de passe, ce qui augmente la portée de la violation. Dans ce cas, l'envoi du mot de passe en texte brut aurait été plus sécurisé car l'attaquant aurait besoin de connaître le texte brut pour se connecter, même en ayant une copie de la base de données. C'est là que la mise en œuvre est essentielle. Que vous envoyiez un mot de passe en clair ou un hachage côté client de ce mot de passe, vous devez hacher cette valeur côté serveur et comparer ce hachage avec le hachage stocké dans l'enregistrement utilisateur.

Concepts à garder à l'esprit:

  • Vous «salez» un hachage en ajoutant une valeur unique à votre champ de hachage, généralement unique à une ligne. Son but est de garantir l'unicité des hachages les uns des autres même si les valeurs en clair qu'ils représentent sont les mêmes, de sorte que deux utilisateurs avec le même mot de passe auraient toujours des hachages différents. Il n'est pas nécessaire de traiter un sel comme un secret.
  • Lors de l'authentification, hachez toujours côté serveur la valeur que vous transmettez du client en tant que mot de passe (même si elle est déjà hachée) et comparez-la à une valeur pré-hachée stockée dans la base de données. Cela peut nécessiter le stockage d'une version à double hachage du mot de passe d'origine.
  • Lorsque vous effectuez un hachage, envisagez d'ajouter un sel unique au serveur / cluster au hachage ainsi qu'un sel unique à la ligne pour vous protéger contre la correspondance des hachages précalculés dans les tables de recherche.
phatfingers
la source