Comment envoyer un mot de passe en toute sécurité via HTTP en utilisant Javascript en l'absence de HTTPS?

Question

La question fondamentale à tous les développeurs face à: 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 que je développe pour ne pas HTTPS. Ni le propriétaire ne veut acheter un certificat SSL, ni est-il intéressé par un auto-signé. Donc, je veux protéger le mot de passe envoyé via HTTP en utilisant Javascript lors de la présentation sous forme.

Pour downvoters désireux: Comment envoyer un mot de passe en toute sécurité sur HTTP ne donne aucune solution raisonnable et je suis dans une autre situation.

Si je MD5, on peut inverser cette chaîne de mot de passe. Qu'en est-nonce / HMAC? Toute bibliothèque Javascript disponible pour cela? Ou avez-vous une suggestion / Hint d'aborder? Merci d'avance!

Answer 1

Il n'y a aucun moyen d'envoyer un mot de passe en toute sécurité que l'utilisateur peut vérifier sans SSL.

Bien sûr, vous pouvez écrire un peu de JavaScript qui fera un mot de passe sécurisé pour over-the-fil transmission par hachage ou de chiffrement à clé publique. Mais comment l'utilisateur peut être sûr que le JavaScript lui-même n'a pas été altéré par un homme en le milieu avant de les atteindre, d'envoyer le mot de passe à un attaquant au lieu du site, ou même juste compromis la sécurité des algorithme? La seule façon serait pour eux d'être des programmeurs experts et de les inspecter chaque ligne de votre page et script pour assurer qu'il était kasher avant de taper le mot de passe. Ce n'est pas un scénario réaliste.

Si vous voulez des mots de passe à l'abri des attaques man-in-the-middle, vous devez acheter un certificat SSL. Il n'y a pas d'autre moyen. Habituez-vous à lui.

  

Si je MD5, on peut inverser cette chaîne de mot de passe.

Non ... pas trivialement au moins. Alors que MD5 a des attaques contre, il est un algorithme de hachage et donc unreversable. Vous auriez à force brute il.

Mais encore une fois, un homme en attaquant le milieu n'a pas besoin de regarder vos MD5s. Il peut tout simplement saboter le JavaScript que vous envoyez à l'utilisateur de faire les MD5s.

Answer 2

La solution est de ne pas envoyer le mot de passe du tout. Utilisez défi / réponse.

Dans la forme originale comprend un grand bloc de texte aléatoire avec une clé. Conservez le texte aléatoire d'origine dans la session en fonction clé sur le serveur. Lorsque le client soumet le formulaire, utilisez JS de hachage du texte aléatoire et mot de passe ensemble. Envoyez ensuite le nom d'utilisateur, la clé et du texte aléatoire hashed au serveur. NE PAS envoyer le mot de passe. Sur le serveur, utilisez la clé pour rechercher le texte aléatoire original, effectuer la même opération de hachage avec le mot de passe stocké. Si la valeur du serveur correspond à la valeur hashed client hachée, alors vous savez que le client est entré dans le bon mot de passe, sans jamais envoyer le mot de passe au serveur.

Que le mot de passe est juste ou non, expireront la clé et du texte au hasard si chacun est un temps d'utilisation.

Answer 3

Si vous voulez vraiment à plonger profondément dans ce, regardez la Diffie Hellman qui a été créée pour « permettre à deux parties qui ont aucune connaissance préalable de l'autre pour établir conjointement une clé secrète partagée sur un canal de communication non sécurisé »

Je ne suis pas un expert en cryptographie, donc je ne sais pas bien si elle est vraiment sûr si un attaquant a à la fois le (code source JavaScript) client et le mécanisme de transport (Packet Sniffer)

Answer 4

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

Mais je crois à la fois celui-ci et en utilisant une fonction de hachage sera vulnérable aux attaques par rejeu . Alors, soyez prudent.

Answer 5

Malheureusement, il n'y aura aucun moyen d'assurer la sécurité d'une demande non cryptée. Toute personne ayant accès à votre javascript simplement pouvoir désossage / falsifier et toute personne ayant un renifleur de paquets sera en mesure de surveiller le trafic non crypté. Ces deux faits signifient:

Non SSL? Pas de sécurité.

Answer 6

Toute transmission que vous avez sera en clair; qui est, sans SSL de vos informations critiques sera exposé. Il est intéressant de discuter ce point avec le propriétaire du site. En d'autres termes, il est préférable de prendre les mesures nécessaires pour renforcer votre transmission de données et SSL est une des étapes de base bon marché, vous pouvez prendre.

Answer 7

Je ne pense pas que la question ici est la technologie, mais comment vous expliquer l'importance de SSL. Leur fournir du matériel de lecture fiables, je suis sûr qu'il ya beaucoup sur le web.

Answer 8

La solution exige que le client pour être en mesure de chiffrer le mot de passe à l'aide d'une clé de chiffrement secret connu que au client et le serveur.

SSL accomplit cela en exigeant à la fois le serveur et le navigateur Web client d'avoir leur propre asymétrique keypair public / privé, qu'ils utilisent pour crypter et transmettre une clé de session aléatoire entre eux. Le reste de la conversation utilise ensuite cette clé de session sécurisée.

Alors, vous vous demandez comment résoudre le même problème que SSL sans l'avantage d'avoir une clé secrète qui est connu uniquement au client et le serveur. Je ne suis pas expert, mais il semble que cela ne peut pas être fait, ou du moins pas facilement.

Answer 9

Si vous n'avez pas accès à SSL, MD5 devrait être suffisant pour empêcher la découverte accidentelle de mots de passe (par exemple dans un fichier journal réseau ou quelque chose). Tout le reste serait une perte de temps. Assurez-vous que l'application ne donne pas accès à des informations sensibles (par exemple, les numéros de carte de crédit, les antécédents médicaux, etc.).

Comme d'autres commentateurs ont suggéré, un attaquant sérieux sera en mesure de briser tout type de sécurité sur la page. Même SSL est une petite barrière puisque la plupart des utilisateurs utilisent des mots de passe faciles à deviner, réutiliser partout les mêmes mots de passe, donnera son mot de passe à personne qui demande ou peut être amené à renoncer à leur mot de passe par une page copiée ou « technologie soutien » appel téléphonique.

Answer 10

- Anglais - Je pense à quelque chose, mais je ne sais pas si cela pourrait être vraiment sûr. Si vous pouvez mettre votre formulaire dans un fichier php, vous pouvez créer un Algoritm pour créer une chaîne basée dans le temps ou dans quelque chose d'autre, puis mettre cette chaîne dans votre html.

Lorsque l'utilisateur tapez un mot de passe dans un champ de saisie de mot de passe, lorsque vous déboguer vous CANOT voyez la valeur saisie par l'utilisateur, donc avant d'envoyer l'information par la poste ou obtenir, vous pouvez utiliser le mot de passe utilisateur comme un indice pour chiffrer la chaîne cryptée previosly générée, puis, juste envoyé insted du mot de passe tapé par l'utilisateur.

De cette façon, les attaquants n'avez pas tout à l'intérieur du code js, donc ils auront besoin de découvrir la Algoritm que vous créez pour le déchiffrer.

Ceci est juste une idée, donc si vous pouvez me dire comment cela ne peut pas être sûr, je vous serais reconnaissant.

- espagnol - Se me Acaba de ocurrir algo que puede attendre until pero no se si realmente mer algo seguro. Por medio de php puedes Générer un algoritmo Que cree chaîne en un socle al horodatage o algo más, y después colocar esta cadena en el html.

Notez Que cuando alguien Escribe una contraseña en un entrée campo tipo mot de passe, con debug un no se puede ver el valor Que tecleo el usuario (no se si exista Manera pero no quise investigar más), asi que Podemos utilizar la contraseña Que el usuario escribió COME palabra clave para la cadena de crypter Texto Que previamente habiamos generado con php, por medio de un algoritmo en JS. Sería algo así COME lo encriptado crypter. Posteriormente lo que estariamos enviado pas sería la contraseña tecleada, si no esta última cadena resultante.

Buscando un contre, lo único Que se me ocurra es que el atacante tendrá Que dedicarle mucho tiempo para tratar de encontrar el agoritmo Que Creamos por medio de php y poder decriptar la cadena finale, o tendrá Que hackear el servidor para Acceder al php y obtener el Algoritmo.

Esto solo una idée, por lo que si pueden decirme COME esto puede ser pas seguro, se los agradeceria.

Answer 11

Comme mentionné précédemment, rien de tout cela est sécurisé contre serveur l'usurpation d'identité, car cela exige une capacité à faire confiance au côté client Javascript. Mais si nous sommes sûrs que le serveur ne peut pas être falsifié (signé cert, signature de hachage immunitaire à la longueur d'extension, etc.), mais pas que la connexion est à l'abri des oreilles indiscrètes, voici comment je d mettre en œuvre.

Je pense que la façon la plus sûre est, au lieu de stocker H ( Mot de passe ), où H est votre fonction de hachage de choix, magasin g ^ H ( mot de passe ) à savoir utiliser le mot de passe de la clé privée pour l'échange de clés Diffie-Hellman. (Vous devez également utiliser probablement un g aléatoire pour différents utilisateurs, trop -. Il devient votre sel) Ensuite, pour vérifier, vous générez un b nonce, envoyer à l'utilisateur g ^ b, et calculer (g ^ H ( mot de passe )) ^ b. L'utilisateur n'a pas besoin de savoir g - dont ils ont besoin unique- (g ^ b) ^ H ( Mot de passe ) = (g ^ H ( Mot de passe )) ^ b. Maintenant, vous avez un certain nombre que les deux parties savent ssi l'utilisateur est entré dans le bon mot de passe, et la construction d'un défi-réponse la preuve zéro connaissances fondées sur la connaissance du nombre exact est trivial, alors que le nombre aléatoire utilisé comme « clé privée » du serveur rend l'approche immunitaire de rejouer les attaques.