Est-il utile de hacher les mots de passe côté client
Lorsque je veux mettre en place un système de connexion, je compare toujours le MD5 du mot de passe donné à sa valeur dans la table des utilisateurs côté serveur.
Cependant, un de mes amis m'a dit qu'un logiciel de réseau pourrait renifler un mot de passe "clair".
Ma question est donc la suivante: est-ce une bonne idée de hacher le mot de passe du côté client? Est-ce mieux que de le hacher côté serveur?
En gros, ton ami a raison. Mais simplement hacher le mot de passe côté client est seulement juste préférable à le soumettre sous forme de texte brut au serveur. Quelqu'un qui peut écouter vos mots de passe en texte brut est également capable d'écouter les mots de passe hachés, et utilise ces hachages capturés pour s'authentifier sur votre serveur.
Pour cette raison, des protocoles d’authentification plus sécurisés sautent généralement à travers un certain nombre de boucles afin de s’assurer qu’une telle attaque par rejeu ne peut pas fonctionner, en général, en permettant au client de sélectionner un ensemble de bits aléatoires, qui sont hachés avec le mot de passe. , et également soumis en clair au serveur.
Sur le serveur:
- générer quelques bits de hasard
- envoyer ces bits (en texte clair) au client
Sur le client:
- générer quelques bits aléatoires
- concaténer le mot de passe, les bits aléatoires du serveur et les bits aléatoires du client
- générer le hachage de ce qui précède
- soumettre des données aléatoires (en texte clair) et hachage au serveur
Comme le serveur connaît ses propres informations aléatoires ainsi que les bits aléatoires du client (il les a reçues en texte clair), il peut effectuer essentiellement la même transformation. Ce protocole veille à ce que personne n'écoutant dans cette conversation ne puisse utiliser les informations ultérieurement pour s'authentifier de manière erronée en utilisant les informations enregistrées (sauf si un algorithme très faible a été utilisé ...), tant que les deux parties génèrent à chaque fois des "bits de bruit" différents, la poignée de main est effectuée.
Edit Tout cela est sujet aux erreurs et fastidieux et quelque peu difficile à obtenir correctement (lire: sécurisé). Si possible, envisagez d'utiliser des implémentations de protocole d'authentification déjà écrites par des personnes bien informées (contrairement à moi! Ce qui précède n'est que la mémoire d'un livre que j'ai lu il y a quelque temps.) Vous ne voulez vraiment pas l'écrire vous-même en général.
Tout d’abord, cela améliore PAS la sécurité de votre application (en supposant qu’il s’agisse d’une webapp).
se SSL (Ou en réalité TLS, communément appelé SSL), ce n’est pas vraiment cher (Mesurez le temps que vous utilisez pour trouver le moyen de le contourner et multipliez-le par le salaire minimum. un certificat gagne presque toujours).
Le pourquoi c'est simple. TLS résout un problème (lorsqu'il est utilisé avec des certificats achetés et non auto-signé) assez important en cryptographie: comment savoir si le serveur auquel je parle est le serveur avec lequel je pense que je parle? Les certificats TLS sont un moyen de dire: "Moi, l’autorité de certification, approuvée par votre navigateur, certifie que le site Web situé à [url] dispose de cette clé publique, ainsi que de la clé privée correspondante (clé privée) que seul le serveur connaît, regarde. J'ai signé ma signature partout sur le document, si quelqu'un l'a modifié, vous pouvez voir ".
Sans TLS, tout cryptage devient inutile, car si je suis assis à côté de vous dans un coffeeshop, je peux faire croire à votre ordinateur portable/smartphone que je suis le serveur et que vous êtes MiTM (Man in the Middle). Avec TLS, votre ordinateur portable/smartphone criera "CONNEXION NON TRAITÉE", car je n'ai pas de certificat signé par une autorité de certification qui correspond à votre site. (Cryptage vs authentification).
Avertissement: les utilisateurs ont tendance à cliquer droit sur ces avertissements: "Connexion non fiable? Quoi? Je veux juste mes photos de chatons! Ajouter une exception Cliquez sur Confirmez Cliquez sur YAY! Chatons! "
Cependant, si vous ne voulez vraiment pas acheter un certificat, quand même implémentez un hachage javascript côté client (et utilisez la bibliothèque standford (SJCL) pour cela, NE JAMAIS IMPLÉMENTER CRYPTO YOURSELF ).
Pourquoi? Réutilisation du mot de passe! Je peux voler votre cookie de session (ce qui me permet de prétendre à votre serveur que je suis vous) sans HTTPS facilement (voir firesheep). Toutefois, si vous ajoutez à votre page de connexion un code javascript qui, avant l’envoi, hache votre mot de passe (utilisez SHA256 ou mieux, utilisez SHA256, envoyez-leur une clé publique que vous avez générée, puis chiffrez le mot de passe haché avec ce mot de passe. avec cela), puis envoie le mot de passe haché/crypté au serveur. REHASH le hachage sur votre serveur avec un sel et comparez cela à ce qui est stocké dans votre base de données (stockez le mot de passe comme ceci:
(SHA256(SHA256(password)+salt))
(enregistrez également le sel en texte clair dans la base de données)). Et envoyez votre mot de passe comme ceci:
RSA_With_Public_Key(SHA256(password))
et vérifiez votre mot de passe comme ceci:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Parce que, SI quelqu'un renifle votre client, il pourra se connecter en tant que votre client (détournement de session) mais il le fera JAMAIS voir le mot de passe en texte brut (à moins qu’ils modifient votre javascript, cependant, un pirate de starbucks ne saura probablement pas comment/s’intéresser à cela.) Ainsi, ils auront accès à votre application Web, mais pas leur email/facebook/etc. (pour lequel vos utilisateurs utiliseront probablement le même mot de passe). (L'adresse e-mail sera soit leur nom d'utilisateur, soit dans leur profil/paramètres de votre application Web).
Vous pouvez probablement ne pas vous inquiéter à ce sujet - comme Dirk le mentionne, même si vous hachez les mots de passe, un utilisateur malveillant pourrait se trouver sur un réseau et voir le hachage être envoyé, et pourrait simplement envoyer le même hachage.
C’est légèrement mieux, en ce sens qu’il empêche l’utilisateur malveillant de savoir quel est le mot de passe, mais qu’il peut toujours se connecter (ou éventuellement reconstruire le mot de passe original ) , ce n'est pas si utile.
En général, si vous êtes préoccupé par la sécurité des mots de passe et des données de vos utilisateurs (et vous devriez l'être!), Vous voudrez utiliser un serveur SSL sécurisé. Si cela ne vous concerne pas pour une raison quelconque, vous pourriez aussi bien ne pas vous embêter avec le hachage; c'est juste sécurité par l'obscurité .
Edit Aug 2014: Google pousse de plus en plus fort pour les sites Web vers passer à HTTPS partout , car la sécurisation de la communication est essentielle le seul moyen d'empêcher les attaques par détection de réseau. Les tentatives d’obscurcissement des données transmises ne feront qu’obstruer, et non arrêter, un attaquant dédié, et pourront donner aux développeurs un dangereux faux sentiment de sécurité.
En réalité, je ne suis pas d'accord pour dire que le hachage côté client est plus sécurisé dans ce cas. Je pense que c'est moins sécurisé.
Le point entier de stocker un hachage du mot de passe dans votre base de données, par opposition au mot de passe réel (ou même à un mot de passe chiffré), est qu’il est mathématiquement impossible d’obtenir le mot de passe original à partir d’un hachage (bien qu’il soit théoriquement possible d’obtenir une collision. entrée de hachage, dont la difficulté dépend de la sécurité de l’algorithme de hachage). Le vecteur d’attaque possible ici est que si un attaquant potentiel compromettait votre base de données de stockage de mots de passe, il/elle ne pourrait toujours pas obtenir les mots de passe originaux de vos utilisateurs.
Si votre mécanisme d'authentification envoie un hachage du mot de passe, dans ce scénario de violation de la sécurité, l'attaquant n'a pas besoin de connaître le mot de passe réel. Il envoie simplement le hachage qu'il possède et hop, il a accès au compte d'un utilisateur particulier. et par extension, tout votre système. Cela élimine complètement le point de stocker un mot de passe haché en premier lieu!
Pour ce faire, le moyen le plus sûr consiste à envoyer au client une clé publique unique lui permettant de chiffrer le mot de passe, puis de le déchiffrer et de le hacher à nouveau côté serveur.
À propos, ce genre de question obtiendra probablement plus de réponses d'experts sur Security StackExchange.
Cela dépend, vous pouvez utiliser le hachage côté client, mais le sel côté serveur ne sera pas possible.
regardez le lien Cryptage du mot de passe côté client
Notez que la sécurité des mots de passe contre les tiers n'est pas tout.
Dès que la vie privée est en jeu (et quand cela ne l'est jamais, ces jours-ci?) vous ne voulez pas connaître le mot de passe. Vous ne pouvez pas abuser ou divulguer ce que vous n'avez pas avoir, afin que vous et vos clients puissiez mieux dormir si vous ne voyez jamais leurs mots de passe en texte clair.
Par conséquent, le hachage/chiffrement côté client est logique.
GitHub et Twitter ont récemment annoncé que les mots de passe étaient stockés dans des journaux internes. Cela est arrivé par inadvertance dans les rapports de bugs et autres journaux qui ont trouvé leur chemin dans Splunk, etc. Pour Twitter, si le mot de passe de Trump était dans ce journal, cela pourrait être un gros problème pour un administrateur de "voir", pour d'autres sites probablement pas aussi un gros problème car les administrateurs ne l'utilisent pas beaucoup. Peu importe en tant qu'administrateur, nous n'aimons pas voir les mots de passe.
La question est donc vraiment de savoir si le hachage doit se produire côté client pour la sécurité, mais comment pouvons-nous protéger le mot de passe avant qu'il ne soit finalement haché et comparé par le côté serveur afin qu'il ne soit pas journalisé d'une manière ou d'une autre.
Le chiffrement n’est pas une mauvaise idée, car les développeurs doivent au moins sauter quelques étapes. Si vous constatez que les mots de passe sont entrés dans les journaux, vous pouvez simplement modifier la clé de chiffrement, détruire l’original et les données deviennent inutiles. Mieux encore, tournez les clés tous les soirs et cela réduirait considérablement les fenêtres.
Vous pouvez également hacher un hachage dans votre enregistrement d'utilisateur. Les mots de passe divulgués seraient des mots de passe en texte brut haché. Le serveur stockerait une version hachée du hachage. Bien sûr, le hachage devient le mot de passe, mais à moins que vous n'ayez une mémoire photographique, vous ne vous souviendrez pas d'un byyr de 60 caractères. Sel avec le nom d'utilisateur. Si vous pouviez rassembler quelque chose à propos de l'utilisateur pendant le processus de connexion (sans exposer le fait que l'enregistrement de l'utilisateur existe), vous pouvez également créer un hachage plus robuste qui ne pourrait pas être partagé entre les sites. Aucun homme au milieu ne pourrait couper et coller le hachage capturé entre les sites.
Combinez-le avec un cookie qui n'est pas soumis au serveur et vous risquez d'être sur quelque chose. À la première demande, soumettez un cookie au client avec une clé, puis assurez-vous que le cookie ne parvient pas au service de connexion et qu’il a donc peu de chances qu’il soit enregistré. Stockez la clé dans un magasin de session, puis supprimez-la juste après la connexion ou à l'expiration de la session ... cela nécessite un état pour vous les gars de JWT, mais utilisez peut-être simplement un service nosql pour cela.
En fin de compte, un administrateur découvre l'un de ces mots de passe hachés et chiffrés dans Splunk ou un outil de rapport de bogue. Cela devrait leur être inutile car ils ne peuvent plus trouver la clé de cryptage, et même s'ils le faisaient, ils doivent alors forcer brutalement un hachage. De plus, l’utilisateur final n’a rien envoyé en texte clair le long de la ligne, de sorte que tout homme du milieu a au moins une période plus difficile et que vous ne pouvez pas simplement aller sur un autre site et vous connecter.
Je travaille beaucoup sur ce sujet récemment. IRL soulève deux problèmes avec le hachage côté client/ symétrique le cryptage supprime vraiment l'idée: 1. Vous devez récupérer le sel vers le serveur QUELQUE CHOSE ... et pour le chiffrer côté client, vous auriez besoin d'un mot de passe ... qui irait à l'encontre du but recherché. 2. Vous exposez votre implémentation de hachage (pas une affaire ÉNORME puisque la plupart des sites utilisent l'un des 3 ou 4 algorithmes de hachage), ce qui facilite l'attaque (il suffit d'essayer l'un plutôt que n).
Ce que j’ai finalement choisi, c’est le chiffrement asymétrique sur le client avec OpenPGP.js ou similaire ... Cela repose sur une clé importée ou générée côté client sur le client et sur le serveur qui envoie sa clé publique. Seule la clé publique du client peut être renvoyée au serveur. Cela protège contre les attaques MIM et est aussi sécurisé que le périphérique (je stocke actuellement la clé privée du client par défaut dans localStore, c'est une démo).
L'avantage MAJEUR de ceci est que je n'ai jamais besoin que les données des utilisateurs soient stockées/même en mémoire non chiffrée sur mon serveur/magasin de données (et la clé privée de mon serveur est physiquement séparée)
La base de ceci était de fournir aux gens un moyen de communiquer en toute sécurité là où HTTPS était restreint (par exemple, Iran/Corée du Nord, etc.) et aussi juste une expérience amusante.
Je suis loin du premier à penser à cela, http://www.mailvelope.com/ utilise
Si quelqu'un peut voir les données entrantes et sortantes sur votre connexion, l'authentification ne vous sauvegardera pas. Je ferais plutôt ce qui suit pour des trucs super secrets.
Les mots de passe pré-achetés côté client avant d'être envoyés au serveur. (Le serveur stocke une autre valeur hachée et salée de ce hachage envoyé par le navigateur).
Ainsi, une attaque intermédiaire pourrait leur permettre d’envoyer la même valeur hachée à leur connexion, mais le mot de passe des utilisateurs ne serait pas connu. Cela les empêcherait d'essayer d'autres services dotés des mêmes informations d'identification pour se connecter ailleurs.
Les données des utilisateurs sont également cryptées du côté du navigateur.
Alors, une attaque entre intermédiaires obtiendrait les données cryptées, mais ne pourrait pas les décrypter sans le mot de passe utilisé pour se connecter. (mot de passe des utilisateurs stocké dans le DOM du navigateur lorsqu’ils se sont connectés). Ainsi, le véritable utilisateur verrait le contenu déchiffré, mais l'homme du milieu ne le pourrait pas. Cela signifie également que tout NSA ou toute autre agence ne pourra pas vous demander/à votre société/à votre fournisseur d'hébergement de déchiffrer ces données, car il leur serait également impossible de le faire.
Quelques exemples de ces deux méthodes sont sur mon blog http://glynrob.com/javascript/client-side-hashing-and-encryption/
Considère ceci:-
Le client envoie une demande au serveur "J'ai un mot de passe pour valider".
Le serveur envoie au client une chaîne aléatoire unique. R $
Le client incorpore le mot de passe de l'utilisateur dans cette chaîne (en fonction des règles (variables) que vous souhaitez appliquer).
Le client envoie la chaîne au serveur et si le mot de passe est correct, le serveur enregistre l’utilisateur dans.
Si le serveur reçoit une autre demande de connexion à l'aide de R $, l'utilisateur est déconnecté et le compte est gelé en attente d'une enquête.
Évidemment, toutes les autres précautions de sécurité (normales) seraient prises.