Lorsque je veux mettre en place un système de connexion, je compare toujours le MD5 du mot de passe donné avec sa valeur dans la table users du côté serveur.
Cependant, un de mes amis m'a dit qu'un mot de passe "clair" pouvait être reniflé par un logiciel de réseau.
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 du côté du serveur ?
En fait, votre ami a raison. Mais simplement hacher le mot de passe du côté client est seulement sólo mieux que de le soumettre en texte brut au serveur. Quelqu'un qui peut écouter vos mots de passe en texte clair est certainement aussi capable d'écouter les mots de passe hachés et d'utiliser lui-même ces hachages capturés pour s'authentifier auprès de votre serveur.
Pour cette raison, les protocoles d'authentification plus sûrs sautent généralement à travers un certain nombre de cerceaux afin de s'assurer qu'une telle attaque par relecture ne peut pas fonctionner, généralement en permettant au client de sélectionner un tas de bits aléatoires, qui sont hachés avec le mot de passe, et également soumis en clair au serveur.
Sur le serveur :
Sur le client :
Comme le serveur connaît ses propres informations aléatoires ainsi que les bits aléatoires du client (il les a obtenus en clair), il peut effectuer essentiellement la même transformation. Ce protocole garantit que personne n'écoutant cette conversation ne peut utiliser les informations plus tard pour authentifier faussement en utilisant les informations enregistrées (à moins qu'un algorithme très faible ait été utilisé...), tant que les deux parties génèrent des "bits de bruit" différents à chaque fois que la poignée de main est effectuée.
Modifier Tout cela est source d'erreurs, fastidieux et quelque peu difficile à mettre en place (lire : sécurisé). Si possible, envisagez d'utiliser des implémentations de protocole d'authentification déjà écrites par des personnes compétentes (contrairement à moi ! Ce qui précède est uniquement tiré de la mémoire d'un livre que j'ai lu il y a quelque temps).
Comment peut-il s'authentifier avec le mot de passe haché dans le système de connexion puisqu'il sera à nouveau haché ?
Si vous stockez vos mots de passe sous forme hachée sur le serveur (comme vous devriez le faire), le client devra hacher le mot de passe deux fois : d'abord, le mot de passe seul, pour qu'il corresponde à la vision du monde du serveur, puis comme décrit ci-dessus pour le protocole.
@Dirk, puisque l'attaquant peut renifler dans les deux sens, les "bits aléatoires" seraient reniflés en même temps. Ensuite, l'attaquant peut analyser (lire : force brute) la paire requête/réponse hors ligne pour trouver le mot de passe original.
Tout d'abord, cela ne PAS améliorer la sécurité de votre application (en supposant qu'il s'agisse d'une webapp).
Utiliser SSL (Ou en fait TLS, qui est communément appelé SSL), il n'est pas vraiment cher (Mesurez le temps que vous utilisez pour trouver des moyens de le contourner et multipliez-le par le salaire minimum, l'achat d'un certificat l'emporte presque toujours).
Le pourquoi de cette situation est simple. TLS résout un problème (lorsqu'il est utilisé avec des certificats achetés, et non auto-signés) qui est assez important en cryptographie : Comment puis-je savoir que le serveur auquel je parle est bien le serveur auquel je pense parler ? Les certificats TLS sont une façon de dire : "Moi, l'autorité de certification, à laquelle votre navigateur fait confiance, certifie que le site web à l'adresse [url] possède cette clé publique, avec une clé privée correspondante, que (clé privée) seul le serveur connaît, regardez j'ai signé ma signature sur tout le document, si quelqu'un l'a modifié vous pouvez le voir".
Sans TLS, tout cryptage devient inutile, car si je m'assois à côté de vous dans un café, je peux faire en sorte que votre ordinateur portable/smartphone pense que je suis le serveur et que je suis l'homme du milieu (MiTM). Avec TLS, votre ordinateur portable/smartphone criera "CONNEXION NON CONTRACTÉE", car je n'ai pas de certificat signé par une autorité de certification correspondant à votre site. (Cryptage contre authentification).
Avertissement : les utilisateurs ont tendance à cliquer sur ces avertissements : "Connexion non fiable ? Quoi ? Je veux juste mes photos de chatons ! Ajouter une exception Cliquez sur Confirmer Cliquez sur YAY ! Des chatons !"
Toutefois, si vous ne voulez vraiment pas acheter de certificat, vous pouvez quand même DO implémenter le hachage javascript côté client (et utiliser la bibliothèque de Standford (SJCL) pour cela, N'INSTALLEZ JAMAIS LA CRYPTOGRAPHIE VOUS-MÊME ).
Pourquoi ? Réutilisation du mot de passe ! Je peux facilement voler votre cookie de session (qui me permet de faire croire à votre serveur que je suis vous) sans HTTPS (voir firesheep). Cependant, si vous ajoutez un javascript à votre page de connexion qui, avant l'envoi, hachera votre mot de passe (utilisez SHA256, ou encore mieux, utilisez SHA256, envoyez-leur une clé publique que vous avez générée puis cryptez le mot de passe haché avec cela, vous ne pouvez pas utiliser un sel avec cela), et ensuite envoie le mot de passe haché/crypté au serveur. RECHAQUER le hachage sur votre serveur avec un sel et le comparer à ce qui est stocké dans votre base de données. (stockez le mot de passe comme ceci :
(SHA256(SHA256(password)+salt))(sauvegarder le sel en clair dans la base de données également)). 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 = okParce que, SI quelqu'un renifle votre client, il pourra se connecter en tant que votre client (détournement de session) mais il JAMAIS voir le mot de passe en clair (à moins qu'ils ne modifient votre javascript, cependant, un pirate de Starbucks ne saura probablement pas comment faire/être intéressé par cela). Ils auront donc accès à votre application Web, mais pas à leur courrier électronique/facebook/etc. (pour lesquels vos utilisateurs utiliseront probablement le même mot de passe). (L'adresse e-mail sera soit leur nom de connexion, soit se trouvera dans leur profil/paramètres sur votre application web).
Je pense qu'il s'agit d'une bonne réponse mais qu'elle nécessite probablement plus d'informations sur la façon de saler correctement et qu'il est préférable d'utiliser une fonction de hachage "lente" avant de stocker le mot de passe sur le serveur (comme bcrypt).
En fait, je ne suis pas d'accord pour dire que le hachage côté client est plus sûr dans ce cas. Je pense que c'est moins sûr.
L'intérêt de stocker un hachage du mot de passe dans votre base de données plutôt que le mot de passe réel (ou même un mot de passe crypté) 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 entrée de hachage en collision, dont la difficulté dépend de la force de sécurité de l'algorithme de hachage). Le vecteur d'attaque possible ici est que si un attaquant potentiel compromettait d'une manière ou d'une autre votre base de données de stockage des mots de passe, il ne serait toujours pas en mesure d'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 vrai mot de passe - il lui suffit d'envoyer le hachage dont il dispose et, hop, il a accès au compte d'un utilisateur particulier et, par extension, à l'ensemble de votre système. Cela va complètement à l'encontre de l'intérêt de stocker un mot de passe haché !
La manière la plus sûre de procéder est d'envoyer au client une clé publique à usage unique pour qu'il crypte le mot de passe, puis de le décrypter et de le recacher sur le serveur.
À propos, ce type de question obtiendra probablement des réponses plus spécialisées sur Security StackExchange.
Tout à fait d'accord avec cela. Pour qu'une approche côté client fonctionne, il faudrait également envoyer le sel au client, ce qui invaliderait l'objectif même du salage !
@JamesWright : Il s'agit d'envoyer un sel aléatoire pour chaque utilisation, ce qui empêche la réutilisation illégale des messages de connexion. (Une forme d'attaque par rejeu). Envoyer le même sel à chaque fois est en effet inutile.
Ce que vous devez faire, c'est utiliser un "nonce" ( fr.wikipedia.org/wiki/Cryptographic_nonce ). De cette façon, le serveur contrôle également le sel et sécurise le tout. Le hachage du côté client est également important afin que le code JS injecté ne puisse pas facilement le retrouver plus tard. Plus d'informations ici : stackoverflow.com/a/21716654/43615
Vous n'avez probablement pas à vous inquiéter de cela - comme Dirk le mentionne, même si vous hachiez 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 lui-même.
Il est légèrement mieux, dans la mesure où il empêche l'utilisateur malveillant de connaître le mot de passe, mais comme il peut toujours se connecter (ou potentiellement reconstituer le mot de passe original ), ce n'est pas très utile.
En général, si vous vous préoccupez de la sécurité des mots de passe et des données de vos utilisateurs (et vous devriez le faire !), vous voudrez utiliser un serveur SSL sécurisé. Si, pour une raison ou une autre, vous n'êtes pas concerné par cette question, vous pouvez tout aussi bien ne pas vous préoccuper du hachage. la sécurité par l'obscurité .
Editer août 2014 : Google pousse de plus en plus fortement les sites web à passer à HTTPS partout car la sécurisation de la communication elle-même est le seul moyen d'empêcher les attaques par reniflage du réseau. Les tentatives d'obscurcissement des données transmises ne feront qu'entraver, et non arrêter, un attaquant déterminé, et peuvent donner aux développeurs un dangereux faux sentiment de sécurité.
Je pense que votre opinion selon laquelle le hachage côté client n'est que "légèrement meilleur" est vraie si vous êtes uniquement pour obtenir x le mot de passe de l'utilisateur et l'accès à un seul service. Si l'on considère l'effet collectif, je dirais que c'est "bien mieux", car cela évite de créer de grandes bases de données de mots de passe utilisées pour forcer des hachages salés dans plusieurs services. IMO. Voir ce que AWS Cognito fait dans le client pour référence.
Cela dépend, vous pouvez utiliser le hachage côté client, mais le sel côté serveur ne sera pas possible.
Jetez un coup d'œil au lien Cryptage du mot de passe côté client
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
Je pensais hacher le mot de passe du côté du client, mais seulement pour être sûr que le mot de passe du client n'existe jamais en clair du côté du serveur, ce qui signifie qu'il peut se sentir plus à l'aise en sachant que je ne connais pas son mot de passe réel, ou que je ne peux pas facilement le donner s'il est compromis.
1 votes
Juste pour être complet, puisque nous parlons de sécurité et que MD5 a été mentionné dans l'OP : Il faut toujours utiliser un sel lors du chiffrement d'un mot de passe. L'utilisation du MD5 brut, non salé, est à peine meilleure que le stockage de mots de passe en clair dans votre base de données.
2 votes
@Cyclone Le hachage SEULEMENT côté client est définitivement une mauvaise idée, car si l'attaquant connaît le hachage, il peut l'utiliser pour se connecter comme s'il connaissait le mot de passe, en contournant le code de hachage côté client.
6 votes
@Teejay : C'est pourquoi vous n'envoyez pas le hachage en clair. Le serveur envoie un sel aléatoire au client, vous ajoutez le hachage du mot de passe, et vous hachurez à nouveau le tout, puis vous renvoyez le tout au serveur qui fait le même calcul. Une attaque par rejeu échoue parce que le sel sera différent.
0 votes
@MSalters Si elle est mise en œuvre comme vous l'avez dit, c'est bon. Mais ce n'est pas ce que cyclone a dit.
3 votes
Cette question ne devrait-elle pas être posée sur security.stackexchange.com ?
1 votes
@sab669 : Parce que cela signifierait que le client enverrait le hachage non salé sur le réseau. Un attaquant peut l'intercepter et effectuer une attaque par rejeu. Mais si le client n'envoie que des hachages salés, un attaquant devrait "déhacher" le message pour changer le sel et réaliser une attaque par rejeu. Et les fonctions de hachage correctes ne peuvent pas être "déhachées". (Ce commentaire vient-il d'être supprimé ?)