Comment envoyer un mot de passe de manière sécurisée via HTTP en utilisant Javascript en l'absence de HTTPS ?

Question

Le problème de base auquel tous les développeurs sont confrontés : Chaque fois que l'utilisateur soumet le formulaire, le mot de passe est envoyé via le réseau et il doit être protégé. Le site pour lequel je développe n'a pas de HTTPS. Le propriétaire ne veut pas acheter de certificat SSL et n'est pas intéressé par un certificat auto-signé. Je veux donc protéger le mot de passe envoyé via HTTP en utilisant Javascript lors de la soumission du formulaire.

Aux fervents supporters : http://stackoverflow.com/questions/1582894/how-to-send-password-securely-over-http NE DONNE PAS de solution raisonnable et je suis dans une autre situation.

Si j'utilise MD5, on peut inverser cette chaîne de mots de passe. Qu'en est-il du nonce/HMAC ? Y a-t-il une bibliothèque Javascript disponible pour cela ? Ou bien avez-vous des suggestions/indications pour y remédier ? Merci d'avance !

Answer 1

Il n'y a aucun moyen d'envoyer un mot de passe de manière sécurisée. que l'utilisateur peut vérifier sans SSL.

Bien sûr, il est possible d'écrire un JavaScript qui sécurise un mot de passe pour une transmission par voie hertzienne grâce à un hachage ou un cryptage à clé publique. Mais comment l'utilisateur peut-il être sûr que le JavaScript lui-même n'a pas été altéré par un homme du milieu avant qu'il ne lui parvienne, pour envoyer le mot de passe à un attaquant au lieu du site, ou même simplement compromettre la sécurité de l'algorithme ? La seule solution serait qu'ils soient des programmeurs experts et qu'ils inspectent chaque ligne de votre page et de votre script pour s'assurer qu'elle est kasher avant de taper le mot de passe. Ce n'est pas un scénario réaliste.

Si vous voulez que les mots de passe soient protégés contre les attaques de type "man-in-the-middle", vous devez acheter un certificat SSL. Il n'y a pas d'autre moyen. Il faut s'y habituer.

Si j'utilise MD5, on peut inverser cette chaîne de mots de passe.

Non... pas trivialement du moins. Bien que MD5 ait des attaques contre lui, c'est un algorithme de hachage et donc irréversible. Vous devriez le forcer brutalement.

Mais là encore, un attaquant de type "man-in-the-middle" n'a pas besoin de regarder vos MD5. Il peut simplement saboter le JavaScript que vous envoyez à l'utilisateur pour créer les MD5.

Answer 2

La solution consiste à ne pas envoyer le mot de passe du tout. Utilisez la méthode défi/réponse.

Dans la forme originale, inclure un grand bloc de texte aléatoire ainsi qu'une clé. Stockez le texte aléatoire original dans la session basée sur la clé sur le serveur. Lorsque le client soumet le formulaire, utilisez JS pour hacher ensemble le texte aléatoire et le mot de passe. Envoyez ensuite le nom d'utilisateur, la clé et le texte aléatoire haché au serveur. N'envoyez PAS le mot de passe. Sur le serveur, utilisez la clé pour rechercher le texte aléatoire original, effectuez la même opération de hachage avec le mot de passe stocké. Si la valeur hachée par le serveur correspond à la valeur hachée par le client, vous savez alors que le client a entré le bon mot de passe sans jamais envoyer le mot de passe au serveur.

Answer 3

Si vous voulez VRAIMENT approfondir ce sujet, regardez la page Échange de clés Diffie-Hellman qui a été créé pour "permettre à deux parties qui n'ont aucune connaissance préalable l'une de l'autre d'établir conjointement une clé secrète partagée sur un canal de communication non sécurisé".

Cependant, je ne suis pas un expert en cryptographie, donc je ne sais pas vraiment si c'est vraiment sécurisé si un attaquant possède à la fois le client (code source JavaScript) et le mécanisme de transport (renifleur de paquets).

Answer 4

Vous pouvez utiliser une implémentation RSA en javascript pour crypter le mot de passe avant de l'envoyer. (Voici un exemple de RSA en Javascript .)

Mais je pense que celle-ci et l'utilisation d'une fonction de hachage seront vulnérables à attaques par relecture . Alors, faites attention.

Answer 5

Malheureusement, il n'y a aucun moyen de garantir la sécurité d'une demande non cryptée. Toute personne ayant accès à votre javascript sera en mesure de le désosser ou de le modifier et toute personne disposant d'un renifleur de paquets sera en mesure de surveiller le trafic non crypté. Ces deux faits ensemble signifient :

Pas de SSL ? Pas de sécurité.