Vous ne pouvez pas.

Pour envoyer des informations en toute sécurité via un canal non sécurisé, vous avez besoin d'un cryptage.

Le chiffrement symétrique est désactivé, car vous devez d'abord transporter la clé, ce que vous ne pouvez pas faire en toute sécurité sur un canal non sécurisé [*].

Cela vous laisse avec la clé publique cryptographie. Vous pouvez bien sûr rouler le vôtre, mais vous ne voulez pas être un Dave, donc c'est fini, ce qui vous laisse avec HTTPS.

_{[*] Vous pouvez bien sûr essayer d'utiliser un canal sécurisé pour échanger la clé, par exemple l'échange physique d'une clé. Ensuite, vous pouvez utiliser une clé secrète crypto, comme Kerberos.}

TLS est vraiment le seul moyen de le faire.

Mais que se passe-t-il si je le crypte avec JavaScript?

L'attaquant peut modifier le JavaScript que vous envoyer au client, ou simplement injecter leur propre JavaScript qui enregistre toutes les informations saisies.

Ensuite, j'utiliserai CSP et SRI pour empêcher l'ajout de scripts et la modification de mes propres scripts.

Heureux que vous utilisiez des outils modernes pour aider à protéger votre site, mais le SRI dans un contexte non sécurisé ne protège vraiment que contre la compromission d'une ressource externe. Un attaquant peut simplement modifier les en-têtes CSP et les balises SRI.

Il n'y a vraiment aucun moyen de faire cela sans utiliser le chiffrement depuis le début, et la seule façon standard de le faire est d'utiliser TLS.

Bien que j'accepte que vous utilisiez HTTPS, vous pouvez le rendre encore plus sécurisé en utilisant le mécanisme d'authentification Salted Challenge Response (SCRAM, voir RFC 5802) pour l'échange d'authentification réel.

Ce n'est pas trivial à mettre en œuvre, mais l'essentiel est que, plutôt que d'envoyer le mot de passe au serveur, vous envoyez la preuve au serveur que vous connaissez le mot de passe. Puisque la dérivation de la preuve utilise un nonce du client et du serveur, ce n'est pas quelque chose qui peut être réutilisé par un attaquant (comme le serait l'envoi du hachage lui-même).

Cela présente quelques avantages supplémentaires à utiliser HTTPS avec l'authentification de base que vous décrivez:

1. Le serveur ne voit jamais réellement votre mot de passe lorsque vous vous connectez. Si quelqu'un a réussi à insérer un code malveillant sur le serveur, il ne saura toujours pas quel est votre mot de passe .
2. S'il y a un bogue dans l'implémentation HTTPS (pensez Heartbleed), les attaquants ne pourront toujours pas acquérir votre mot de passe. Parce que, même une fois que TLS est contourné, le mot de passe n'est pas disponible.
3. Si, pour une raison quelconque, vous ne pouvez pas utiliser HTTPS, c'est mieux que d'envoyer le mot de passe en clair. Un attaquant ne pourra pas deviner votre mot de passe en fonction de l'échange. Cela dit, vous devriez toujours utiliser HTTPS, car la défense en profondeur est meilleure.

Veuillez noter que cela n'est sécurisé que si le client est capable d'effectuer le SCRAM calculs sans télécharger de code depuis le serveur. Vous pouvez fournir un gros client, ou les utilisateurs peuvent être en mesure d'écrire leur propre code qu'ils contrôlent. Le téléchargement du code SCRAM via HTTP donnerait à un attaquant la possibilité de modifier le code SCRAM pour envoyer le mot de passe en texte clair, ou l'exposer autrement.

Vous devez absolument déployer TLS dans ce cas.

Si vous décidez d'essayer d'inventer un système de sécurité de transport sur HTTP, vous finirez par implémenter de toute façon un sous-ensemble de la fonctionnalité TLS. Il y a de nombreux pièges à prendre en compte lors de la conception et de la mise en œuvre d'un tel système, qui sont encore amplifiés lorsque vous choisissez d'essayer d'implémenter le système avec un langage qui n'offre pas beaucoup de fonctionnalités de sécurité.

Même si vous avez implémenté une implémentation correcte d'un protocole cryptographique en JavaScript (ce qui est déjà un gros défi), vous ne pouvez pas compter sur cette implémentation résistante aux attaques de timing, et le tout se brise si quelqu'un a des scripts désactivés (par exemple avec NoScript).

En règle générale, vous devez choisir l'implémentation qui se compose des composants les plus simples, les mieux compris et les plus fiables qui vous obligent à écrire le moins de code critique pour la sécurité. Pour citer Andrew Tannenbaum:

Un grand nombre de problèmes (dans la sécurité des applications) sont causés par des logiciels bogués, qui se produisent parce que les fournisseurs ajoutent de plus en plus de fonctionnalités à leurs programmes, ce qui signifie inévitablement plus de code et donc plus de bogues.

Dois-je implémenter un algorithme de chiffrement comme le chiffrement à clé publique RSA?

Si vous envisagez d'essayer cela, vous pouvez aussi bien faire le plein kilomètre et utiliser HTTPS. Etant donné que vous ne semblez pas être un expert, le chiffrement «roulant vous-même» aura sans aucun doute des erreurs de mise en œuvre qui le rendront non sécurisé.

C'est en fait tout à fait possible.

Le mot de passe doit être haché côté client, mais pas avec une fonction statique. La méthode suivante utilise deux étapes et s'inspire de l ' authentification d'accès Digest:

REMARQUE: Le serveur conserve un HMAC du mot de passe et du code correspondant Clé ( Digest );

1. Le client commence par demander un nonce au serveur, le serveur renvoie la Clé et le Nonce
2. Client calcule: HMAC (HMAC ( Mot de passe , Clé ), Nonce ) et l'envoie au serveur;
3. Le serveur calcule: HMAC ( Digest , Nonce ) et le compare à la valeur reçue.

Cela vous protège contre la relecture.

Le principal intérêt que je vois n'est pas une protection contre les écoutes clandestines, mais d'être complètement sûr que le mot de passe en clair ne sera pas stocké sur le serveur, même pas dans un journal système (voir Twitter ou GitHub).

Remarque: HMAC peut être remplacé par PBKDF2.

Il existe en fait un moyen d'authentifier un utilisateur via une connexion non sécurisée: le protocole SRP (Secure Remote Password). SRP est spécifiquement conçu pour permettre à un client de s'authentifier auprès d'un serveur sans qu'un attaquant Man-in-the-Middle puisse capturer le mot de passe du client, ou même rejouer l'authentification pour usurper ultérieurement l'identité du client, que l'authentification ait réussi ou non. En outre, une authentification réussie avec SRP crée une clé secrète partagée que le client et le serveur connaissent, mais pas un MitM. Cette clé secrète pourrait être utilisée pour le cryptage symétrique et / ou les HMAC.

Cependant, il existe un certain nombre de limitations de SRP:

1. L'utilisateur doit s'être enregistré dans un mode, car le processus d'enregistrement nécessite la transmission d'un matériel équivalent au mot de passe (bien que le serveur n'ait pas besoin de le stocker).
2. Bien qu'il soit sûr de tenter une connexion SRP avec un serveur non approuvé (c'est-à-dire n'exposera pas votre mot de passe à ce serveur, et vous serez en mesure de dire que le serveur n'avait pas votre mot de passe dans sa base de données), Il n'est pas sûr de charger une page Web de connexion à partir d'un serveur non approuvé (cela pourrait envoyer une page qui capture chaque frappe et l'envoie quelque part).
3. Bien que l'authentification réussie via SRP génère une clé secrète partagée sécurisée, le code pour utiliser réellement cette clé dans une application Web doit être chargé à partir de un serveur, et un attaquant pourrait altérer ce code pour voler la clé symétrique et apporter des modifications aux requêtes et réponses.

En d'autres termes, alors que SRP peut être utile dans les situations où vous avez un client de confiance qui n'a pas besoin de télécharger son code via la connexion non sécurisée et que vous disposez également d'un autre moyen sécurisé pour enregistrer le ou les utilisateurs, SRP ne convient pas à une application Web. Les applications Web téléchargent toujours leur code à partir du serveur, donc si la connexion au serveur n'est pas sécurisée, un MitM (ou un autre attaquant du réseau, par exemple quelqu'un qui spoofing DNS) peut injecter un code malveillant dans l'application Web et il n'y a rien que vous la victime peut y remédier. Une fois que ce code est là, il peut capturer n'importe quel mot de passe ou d'autres données que vous entrez, voler n'importe quelle clé générée et falsifier toutes les demandes que vous envoyez ou les réponses que vous recevez sans que vous le sachiez.

Il est certainement possible d'envoyer un mot de passe en toute sécurité en utilisant HTTP. Il existe même une norme pour cela. Il s'appelle HTTP-Digest et il est défini dans la RFC 7616. Cela fait partie de la spécification HTTP depuis un certain temps. Il a été conçu à l'origine pour n'utiliser que l'algorithme MD5 message-digest ("hashing"), mais les révisions ultérieures de la norme permettent au client et au serveur de négocier l'algorithme à utiliser.

Malheureusement, il y a beaucoup de problèmes avec HTTP-digest et le plus flagrant d'entre eux est que le serveur doit avoir le mot de passe en clair . Ainsi, bien qu'il soit possible de communiquer des mots de passe en toute sécurité à l'aide de HTTP, il n'est pas possible de stocker en toute sécurité les mots de passe sur le serveur tout en l'utilisant. Donc, fondamentalement, ce n'est pas utile.

Comme d'autres l'ont dit, il serait préférable d'implémenter TLS car il résout plusieurs problèmes en même temps, et il est assez compatible.

Comme d'autres l'ont dit TLS! TLS! TLS! (et avec une longueur de clé décente aussi)

Mais si vous devez utiliser HTTP et n'importe quel serveur à implémenter, est-ce pour un usage programmatique ou humain? Si pour un usage humain, recherchez-vous l'authentification de base ou basé sur un formulaire? Et vos utilisations sont-elles capables d'appliquer un peu de logique, par exemple. pas pour joe public à utiliser. Est-ce que quelque chose d'autre doit être protégé, ou juste le mot de passe lui-même?

Si c'est le cas, vous pourrez peut-être regarder:

• Utilisez un pad / générateur de mot de passe à usage unique (les porte-clés RSA ne sont pas bon marché, et si vous avez ce genre d'argent à dépenser, vous pouvez vous permettre TLS)
• Une autre authentification à 2 facteurs comme les SMS (pas sans ses propres problèmes).
• Un simple mécanisme de défi / réponse pour masquer le mot de passe, par exemple la page affiche deux chiffres dessus dans le texte (pas de façon flagrante non plus), l'utilisateur doit démarrer le mot de passe avec un calcul simple comme la différence entre les deux nombres ajoutés à chaque chiffre d'un code PIN, peut-être avec des éléments aléatoires avant et / ou et après, par exemple 98634572dkkgdld. La modification des numéros de défi devrait arrêter les attaques de relecture qui ne sont pas tentées instantanément, mais si un attaquant peut capturer suffisamment de tentatives, il peut être en mesure de résoudre le problème. Vous ne pouvez pas non plus mettre de logique d'obscurcissement dans un script destiné à l'utilisateur, car cela sera vu et si le schéma est trop complexe, vos utilisateurs vous détesteront encore plus.

Cependant, avec TLS, les certificats sont bon marché (même gratuits) de nos jours, donc les schémas d'obfuscation compliqués n'ont plus aucune raison d'exister.