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

J’ai remarqué que la plupart des sites envoyaient les mots de passe en texte brut sur 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 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 doivent jamais être conservés (encore moins transmis) en texte clair. Cela signifie pas gardé sur le disque, ou même en mémoire.

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

Il n’y a vraiment pas besoin de savoir quel est le mot de passe original. Tout ce qui est requirejs est un moyen fiable de générer (et de générer de manière fiable) une “clé” d’authentification 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 la hachant en utilisant 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 manière, 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 est paresseux et utilise 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 avoir cette clé dans vos systèmes. Vous ne devez jamais transmettre une clé ou un mot de passe “en clair”. Même pas sur HTTPS. HTTPS n’est pas impénétrable. En fait, de nombreuses entresockets peuvent devenir un MITM de confiance, non pas du sharepoint vue des attaques, mais pour effectuer des inspections sur le trafic afin de mettre en œuvre leurs propres stratégies de sécurité. Cela affaiblit HTTPS, et ce n’est pas la seule façon dont cela se produit (comme les redirections vers les attaques HTTP MITM par exemple). Ne supposez jamais que c’est sécurisé.

Pour contourner ce problème, nous avons haché la clé avec un nonce unique. Ce nonce est unique pour chaque envoi d’une clé à vos systèmes – même pour les mêmes identifiants lors d’une 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 ferais irréversiblement une dernière fois avant qu’il ne soit définitivement stocké dans vos propres systèmes. De cette façon, vous pouvez partager les informations d’identification avec des organisations partenaires pour les besoins de l’authentification unique et autres, tout en pouvant 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 quelque chose généré par l’utilisateur sans son autorisation.

Faites plus de recherches, car il ya plus que ce que j’ai divulgué, mais si vous voulez offrir une véritable sécurité à vos utilisateurs, je pense que cette méthode est actuellement la plus complète.

TL; DR:

Utilisez HTTPS. Des mots de passe sécurisés, irréversiblement, avec un sel par mot de passe unique. Faites cela sur le client – ne transmettez pas son mot de passe réel. Transmettre le mot de passe d’origine des utilisateurs à vos serveurs n’est jamais “OK” ou “Bien”. Nettoyez toute trace du mot de passe original. Utilisez un nonce indépendamment de HTTP / HTTPS. Il est beaucoup plus sécurisé à plusieurs niveaux. (Réponse à OP).

Comme il est sur HTTPS, il est tout à fait approprié d’envoyer le mot de passe sans hachage (via HTTPS, ce n’est pas du texte en clair). En outre, si votre application dépend de HTTPS pour garder son contenu sécurisé, il est inutile de hacher le mot de passe avant de l’envoyer via HTTPS (si un attaquant peut décrypter les données sur le câble, vous êtes de toute façon vexé)

Non, en fait ce serait une vulnérabilité. Si l’attaquant est capable d’obtenir le hachage de la firebase database, il pourrait l’utiliser pour s’authentifier sans avoir à le déchiffrer. En aucun cas, un utilisateur ou un attaquant ne peut obtenir un mot de passe de hachage.

L’intérêt de hacher des mots de passe est d’append une couche de sécurité supplémentaire. Si un attaquant est capable d’obtenir le hachage et le sel de la firebase database en utilisant une injection SQL 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: Protection de la couche de transport A9 insuffisante

EDIT: Si dans votre implémentation, vous calculez un sha256(client_salt+plain_text_password) et calculez ensuite un autre hachage côté serveur sha256(server_salt+client_hash) cela ne représente pas une vulnérabilité grave. Cependant, il est toujours susceptible d’écouter et de rejouer la demande. Il s’agit donc toujours d’une violation claire du WASP A9. Cependant, cela utilise toujours un résumé de message en tant que 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 une violation de la norme OWASP A9. Les auteurs du code reconnaissent qu’il ne s’agit pas d’un remplacement complet du HTTPS, mais qu’il vaut mieux que rien et mieux qu’un système de hachage côté client.

Envoyer un hachage sur le câble annule complètement le but du hachage, car un attaquant peut simplement envoyer le hachage et oublier le mot de passe. En résumé, un système qui authentifie l’utilisation d’un hachage en texte clair est largement ouvert et peut constituer un compromis avec rien de plus que le reniflage réseau.

Le mot de passe en texte brut ne s’affiche jamais (même lorsque vous utilisez HTTPS), quittez le client. Il doit être irréversiblement haché avant de quitter le client, car le serveur n’a pas besoin de connaître le mot de passe réel.

Le hachage puis la transmission résolvent les problèmes de sécurité pour les utilisateurs paresseux qui utilisent le même mot de passe dans plusieurs endroits (je sais que je le fais). Cependant, cela ne protège pas votre application car un pirate ayant eu access à la firebase database (ou pouvant de toute autre manière mettre la main sur le hachage) car le pirate pouvait simplement transmettre le hachage et le faire accepter par le serveur.

Pour résoudre ce problème, vous pouvez bien sûr hacher le hash que le serveur reçoit et l’appeler un jour.

Mon approche du problème dans une application Web basée sur des sockets que je crée est que, lors de la connexion au client, le serveur génère un sel (chaîne aléatoire à append avant le hachage) et le stocke dans la variable sockets. 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 la firebase database + sel). 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 à propos de quelque chose, j’aimerais être corrigé 🙂

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’access 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’access de base, ce qui permet d’établir l’identité de l’utilisateur de manière sécurisée sans avoir à envoyer un mot de passe en texte brut sur le réseau. L’authentification Digest est essentiellement une application du hachage cryptographique MD5 avec utilisation de valeurs nonce pour empêcher la cryptparsing.

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 à http://php.net/manual/en/features.http-auth.php

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

De mes tests tous les navigateurs modernes le supportent …

Si vous souhaitez remplacer un mot de passe en texte clair par HTTPS avec un mot de passe haché sur HTTP, vous posez 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 à casser, car vous êtes assez limité à forcer la clé partagée utilisée pour une transaction (relativement) à court terme. Alors que votre hash peut simplement être reniflé, mis hors-ligne et regardé dans une table arc-en-ciel ou simplement brute forcée pendant une longue période.

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 effectivement utilisée par certaines banques. Le but de cette technique n’est pas de protéger le mot de passe contre le reniflage par fil. Il s’agit plutôt d’empêcher que le mot de passe ne soit utilisé par les outils d’espionnage et les plug-ins de navigateur qui capturent 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 aléatoires GET / POST capturées à partir de sessions utilisateur. Vous pouvez imaginer que les sites Web qui utilisaient uniquement HTTPS apparaissaient avec des mots de passe en texte clair dans le journal, mais que les sites Web présentant des problèmes de base (ROT13) apparaissaient également avec des mots de passe qui ne sont pas immédiatement utilisés.

Disclaimer: Je ne suis en aucun cas un expert en sécurité – et je poste avec l’ espoir que d’autres critiqueront ma position comme étant trop prudente ou que je pourrai améliorer. Cela dit, je veux juste souligner que le hachage quand il quitte votre client ne signifie pas que vous ne devez pas avoir de hachage sur le backend avant de le mettre dans la firebase database.

Faire les deux

Faites les deux parce que:

  1. Hashing sur le trajet permet de couvrir les vulnérabilités de transport, si la connexion SSL est compromise, ils ne peuvent toujours pas voir le mot de passe brut. Cela n’a aucune importance en termes de pouvoir usurper l’identité d’utilisateurs autorisés, mais cela protégera vos utilisateurs contre la lecture de leurs mots de passe en association avec leur courrier électronique. La plupart des gens ne suivent pas les meilleures pratiques et utilisent le même mot de passe pour beaucoup de leurs comptes, ce qui peut constituer une grave vulnérabilité pour vos visiteurs.

  2. Si quelqu’un pouvait en quelque sorte lire les mots de passe de la firebase database (cela arrive, pensez à l’injection SQL), ils ne pourront toujours pas exécuter des actions privilégiées imitant les utilisateurs via mon API. Ceci est dû à une asymésortinge de hachage; même s’ils connaissent le hachage stocké dans votre firebase database, ils ne connaîtront pas la clé d’origine utilisée pour la créer et c’est ce que votre middleware d’authentification utilise pour s’authentifier. C’est pourquoi vous devez toujours saler votre espace de stockage.

Certes, ils pourraient faire beaucoup d’autres dégâts s’ils avaient la liberté de lire ce qu’ils veulent de votre firebase database.

Je veux juste souligner ici que si vous décidez de hacher la clé avant le départ de vos clients, cela ne suffit pas – le hachage de backend est, imo, beaucoup plus important et c’est pourquoi: si quelqu’un intercepte le trafic de votre client, ils verront 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 intégralement pour usurper l’identité d’un client autorisé. (Sauf si vous suivez les étapes qui @ user3299591 décrit, et je vous recommande de le faire). En revanche, le hachage de la colonne DB est une nécessité et pas du tout difficile à mettre en œuvre.

Si vous êtes connecté à un serveur https, le stream de données entre le serveur et le navigateur doit être crypté. Les données ne sont que du texte brut avant leur envoi et après leur réception. Article de Wikipedia

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.

SSL / TLS ne remplace-t-il pas le nonce? Je ne vois pas de valeur ajoutée car SSL / TLS protège également contre les attaques par rejeu.

Réf. https://en.wikipedia.org/wiki/Cryptographic_nonce