Dois-je hacher le mot de passe avant de l'envoyer côté serveur?
J'ai remarqué que la plupart des sites envoient les mots de passe en 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?
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 sur HTTP - uniquement HTTPS, mais beaucoup semblent répondre à la question de l'envoi d'un mot de passe sur HTTP pour une raison quelconque. Cela dit:
Je pense que les mots de passe ne doivent jamais être conservés (et encore moins transmis) en texte clair. Cela signifie qu'il n'est pas conservé sur disque, ni même en mémoire.
Les personnes qui répondent ici semblent penser que le HTTPS est une solution miracle, ce qui n'est pas le cas. Cependant, cela aide 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 d'origine. Tout ce qui est requis est un moyen fiable de générer (et de recréer de manière fiable) une authentification "clé" basée sur le texte original choisi par l'utilisateur. Dans un monde idéal, ce texte devrait immédiatement générer une "clé" en le hachant avec du sel irréversible. Ce sel doit être unique pour les informations d'identification utilisateur générées. Cette "clé" sera ce que vos systèmes utiliseront comme mot de passe. De cette façon, si vos systèmes sont compromis à l'avenir, ces informations d'identification ne seront 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é. Maintenant, nous devons 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 via 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 irréversiblement une dernière fois avant qu'il ne soit stocké en permanence dans vos propres systèmes. De cette façon, vous pouvez partager le sel des informations d'identification avec des organisations partenaires à des fins d'authentification unique et similaires, 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 en a plus que moi-même, mais si vous voulez offrir 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 son 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. Il est beaucoup plus sécurisé à plusieurs niveaux. (Réponse à OP).
Puisqu'il est sur HTTPS, il est certainement très bien 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, il est inutile de hacher le mot de passe avant de l'envoyer via HTTPS (c'est-à-dire si un attaquant peut décrypter les données sur le câble, vous êtes quand même foutu)
Non, en fait, ce serait une vulnérabilité. Si l'attaquant est en mesure d'obtenir le hachage de la base de données, il pourrait l'utiliser pour s'authentifier sans avoir besoin de le casser. En aucun cas, un utilisateur ou un attaquant ne devrait 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 à l'aide de SQL Injection ou d'une sauvegarde non sécurisée, il doit trouver le texte brut en le forçant brutalement. John The Ripper est couramment utilisé pour briser les hachages salés de mot de passe.
Ne pas utiliser https est une violation du Top 10 OWASP: A9-Insufficient Transport Layer Protection
EDIT: Si dans votre implémentation vous calculez une sha256(client_salt+plain_text_password) puis calculez un autre hachage côté serveur sha256(server_salt+client_hash) alors 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 du 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 est 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.
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 authentifie l'utilisation d'un hachage en texte clair est grand ouvert et peut être compromis avec rien de plus que le reniflement du réseau.
Le mot de passe en clair affiche ne quitte jamais (pas même en utilisant HTTPS) 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 qui a accédé à la base de données (ou de toute autre manière a pu mettre la main sur le hachage) car le pirate pourrait simplement transmettre le hachage et demander au serveur de l'accepter.
Pour résoudre ce problème, vous pouvez bien sûr simplement hacher le hachage que le serveur reçoit et l'appeler un jour.
Mon approche du problème dans une application Web basée sur un 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 dans 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 sel DB +). 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, j'aimerais être corrigé :)
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 à résoudre, car vous êtes pratiquement limité à forcer brutalement 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 Rainbow ou simplement brutal forcé pendant une longue période de temps.
Cependant, une obfuscation de mot de passe côté client de base (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 de renifler sur le fil. Il s'agit plutôt d'empêcher le mot de passe d'être utilisé par des outils d'espionnage stupides et des plug-ins de navigateur qui récupèrent simplement chaque demande HTTPS GET/POST qu'ils voient. J'ai vu un fichier journal capturé à partir d'un site Web malveillant qui représentait 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 s'afficheraient avec des mots de passe en texte clair dans le journal, mais les sites Web avec une obfuscation très basique (ROT13) apparaîtraient également avec des mots de passe qui ne sont pas immédiatement utilisés.
Utilisez HTTP Digest - il sécurise le mot de passe même sur http (mais la meilleure utilisation serait http digest sur https)
Wikipédia:
L'authentification d'accès HTTP HTTP est l'une des méthodes convenues qu'un serveur Web peut utiliser pour négocier des informations d'identification avec un utilisateur Web (en utilisant le protocole HTTP). L'authentification Digest est destinée à remplacer l'utilisation non cryptée de l'authentification d'accès de base, permettant à l'identité de l'utilisateur d'être établie 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 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 openp php qui utilise l'authentification http digest http://siege.org/phpmyid.php
.. ou vous pouvez commencer à partir des exemples d'authentification php sur 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 ...
Avertissement: je ne suis en aucun cas un expert en sécurité - et je poste avec le espérons que d'autres critiqueront ma position comme trop prudente ou évolutive et j'en tirerai des leçons. Cela dit, je tiens à souligner que le hachage lorsqu'il quitte votre client ne signifie pas que vous n'avez pas à hacher sur le backend avant de le mettre dans la base de données.
Faites les deux
Faites les deux parce que:
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 possibilité d'usurper l'identité des utilisateurs autorisés, mais cela protégera vos utilisateurs de la lecture de leurs mots de passe en association avec leur e-mail. La plupart des gens ne suivent pas les meilleures pratiques et n'utilisent pas le même mot de passe pour plusieurs de leurs comptes, cela peut donc être une vulnérabilité sérieuse pour vos visiteurs.
Si quelqu'un, d'une manière ou d'une autre, a pu lire les mots de passe de la base de données (cela se produit, pensez à l'injection SQL), il ne pourra toujours pas exécuter des actions privilégiées usurpant l'identité des utilisateurs via mon API. Cela 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 aussi 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 voulaient de 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, imo, beaucoup plus important et c'est pourquoi: Si quelqu'un intercepte le trafic de votre client, ils verront alors le contenu du champ password. Qu'il s'agisse d'un hachage ou d'un texte brut, cela n'a pas d'importance - ils peuvent le copier textuellement pour usurper l'identité d'un client autorisé. (À moins que vous ne suiviez les étapes décrites par @ user3299591, et je vous le recommande). Le hachage de la colonne DB, d'autre part, est une nécessité et pas du tout difficile à mettre en œuvre.
Si vous êtes connecté à un serveur https, le flux de données entre le serveur et le navigateur doit être crypté. Les données ne sont que du texte brut avant d'être envoyées et après avoir été reçues. article Wikipedia
SSL/TLS ne remplace-t-il pas le nonce? Je ne vois pas de valeur ajoutée à cela car SSL/TLS protège également contre les attaques de relecture.
Il serait en fait moins sûr de hacher le mot de passe et de l'envoyer sur un canal non crypté. 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 pirate d'obtenir le mot de passe d'une seule source, car HTTPS utilise deux canaux, tous deux cryptés.