Pas de SSL, pas de sécurité. Les choses dans le monde réel sont rarement simples, mais ici c'est le cas. Cela se voit facilement comme suit: tout ce que vous faites en Javascript, se fera en Javascript envoyé par le serveur . Tout attaquant qui est en mesure de regarder les données peut également les modifier à volonté (par exemple, le moyen le plus simple d'espionner le WiFi est d'exécuter votre propre faux point d'accès, puis vous pouvez naturellement modifier toutes les données au fur et à mesure) ; ainsi, un tel attaquant peut simplement supprimer ou modifier la solution Javascript que vous pourriez proposer et la désactiver. Ou ajoutez simplement un crochet pour également envoyer le mot de passe en clair comme paramètre supplémentaire.

Maintenant, même si vous pouviez obtenir du «Javascript sûr» sur le navigateur client, vous rencontreriez alors tous les problèmes liés à la crypto Javascript, et qui sont détaillés dans l'article auquel vous créez un lien. Mais ce n'est qu'une considération secondaire, par rapport à la faille fondamentale expliquée ci-dessus: sans SSL, vous ne pouvez pas vous assurer que ce qui s'exécute sur le navigateur client est votre code.

Essayer de gérer le mot de passe en toute sécurité sur un site Web non SSL revient à essayer d'effectuer une chirurgie cérébrale en toute sécurité avec seulement une cuillère à café et un pied de biche rouillé. Ne fais pas ça. S'il y a des données sensibles qui circulent vers le site Web (par exemple des noms et des adresses), vous DEVEZ appliquer des mécanismes de protection raisonnables. Si les données ne sont pas sensibles, pourquoi auriez-vous besoin de mots de passe?

À mon humble avis, le générateur de nombres aléatoires est le moindre de vos soucis ici. Puisque le code pour invoquer l'enceyption est envoyé en clair, il est trivial pour quelqu'un de MITM l'interaction.

Si le service nécessite le niveau de sécurité fourni par le cryptage et est fourni par un site Web, alors il DOIT utiliser HTTPS (et idéalement tous les éléments de sécurité associés comme les cookies secure + httponly et HSTS).

Le seul moyen de contourner ce problème serait d'écrire une application HTML5 (où le le code est rarement téléchargé) - mais même cela présente des inconvénients importants.

La meilleure solution, comme cela a été dit, est d'obtenir un véritable plan d'hébergement Web qui autorise https. Cela ne devrait pas être trop cher, en fait il devrait même être possible de trouver un fournisseur gratuit pour fournir cela.

À défaut, quel est votre cas d'utilisation? Il semble que vous ayez à l'esprit un groupe d'utilisateurs défini pour votre site Web. Si tel est le cas et que vous n'offrez pas simplement un service de notification d'événements basé sur un abonnement à des personnes aléatoires sur Internet, envisagez de fournir la base d'une connexion `` sécurisée '' sur un canal différent.

Cela se produit pour moi, qu'obtenir le code sur leur machine par une autre source fiable (poster des CD par courrier postal et les informer par e-mail, simplement envoyer le logiciel en pièce jointe à un e-mail signé numériquement, etc.) vous permet de précharger le logiciel avec une clé publique cryptographique.

Vous pouvez alors négocier une connexion sécurisée via une méthode de connexion non sécurisée (telle que http) car le code déterminant si le serveur a déchiffré de manière satisfaisante les détails cryptés avec sa clé publique vit le client. Un flux de données d'application http "en clair" est le résultat, avec la ride que les données d'application elles-mêmes sont cryptées.

C'est beaucoup de problèmes et une méthode non standard. Vous rencontrez des problèmes de mise en œuvre car peu de personnes l'auront essayé pour vous conseiller, et de sécurité puisque peu de personnes en ont revu sa fiabilité *.

Le canal alternatif peut lui-même avoir des problèmes de sécurité. Le courrier pourrait-il être intercepté? Les fraudeurs pourraient-ils se faire passer pour votre organisation et envoyer leur propre version «sécurisée» de votre logiciel? Vos utilisateurs sont-ils suffisamment avertis pour vérifier les signatures numériques des e-mails que vous envoyez? Ce sont toutes des préoccupations que vous devrez considérer et accepter comme risques ou tenter d'atténuer avec de nouvelles solutions, car vous avez moins de conseils non seulement sur la façon de mettre en œuvre, mais même sur les questions que vous devez poser (vous devrez plus que ces trois!).

Lorsque vous parlez à la direction de l'ONG, pensez à décrire la situation en ces termes:

1. Cette dernière méthode comporte des risques importants et finira par leur coûter plus de temps à mettre en œuvre que cela ne le fera simplement payer pour l'hébergement - le programme doit être mis à jour, surtout si le serveur (ou la paire de clés du serveur) change, et continuellement distribué aux nouveaux utilisateurs après le déploiement initial.
2. Ne rien faire du tout et utiliser un mot de passe http avec des adresses et des noms (et potentiellement des adresses e-mail) pourrait être un désastre de relations publiques en cas de fuite d'informations (et ce sera le cas), un risque important. Cela est aggravé par le fait que les gens réutilisent les mots de passe et que votre mauvaise pratique pourrait être liée à des violations ultérieures.
3. Vous avez ainsi réfléchi à la situation et vous n'allez pas simplement suggérer la solution décrite dans étape 4 parce que «tout le monde le fait» (bien que, dans le cas où tout le monde le fait parce que c'est la meilleure pratique, ce n'est pas une mauvaise chose). Être en mesure de proposer la solution alternative (si compliquée et excessive) décrite dans les étapes 1 & 2 est la preuve de cette diligence raisonnable.
4. Sur cette base, l'hébergement https avec un coût continu faible (ou nul) est approche à la fois la moins coûteuse ET la moins risquée.

* Jonathan Gray explique pourquoi vous rencontrerez des problèmes de codage d'un système sécurisé dans sa réponse, regardez la section commençant par "TLS est aussi un système beaucoup plus intrinsèque"

Commencez par remplacer votre hôte.

Obtenir des certificats SSL est plus facile que jamais grâce aux autorités de certification gratuites. LetsEncrypt, par exemple, propose des certificats de validation de domaine SSL / TLS gratuits de manière automatisée à condition que vous soyez propriétaire du nom de domaine. Il y a plus d'explications dans la réponse de StackzOfZtuff sur ses fonctionnalités.

Il y a des instructions sur la façon de le configurer sur leur site communautaire avec des FAQ et un forum d'aide .

Le problème avec JS est la génération de nombres aléatoires (qui est vitale pour la sécurité du chiffrement moderne). Il existe des bibliothèques existantes disponibles qui aident à résoudre ce problème, mais vous devez vous assurer que la bibliothèque utilise crypto.getRandomValues ​​ ainsi que la possibilité d'obtenir de l'entropie à partir d'une entrée humaine (telle que l'activité de la souris ou du clavier) . Ceci est particulièrement lourd pour les appareils mobiles, cependant, surtout si l'on considère le fait que le matériel lui-même est moins capable de générer des nombres aléatoires sécurisés.

Je voudrais également ajouter un point supplémentaire sur RSA. Vous ne pouvez chiffrer que de petites quantités de données avec lui, et la quantité de données est relative à la longueur de clé utilisée. Non seulement cela, mais RSA est lent. Si vous avez besoin d'une quantité décente de données ou si vous faites plusieurs demandes au serveur, je vous recommande de chiffrer une clé aléatoire (CSPRNG) avec JS côté client en utilisant la clé publique du serveur et d'utiliser cette clé pour un chiffrement symétrique.

Edit: TLS est aussi un système beaucoup plus intrinsèque qui travaille très dur pour se protéger contre toutes sortes d'attaques. Le seul type d'attaque contre lequel TLS ne protège pas efficacement est une déconnexion forcée. Tout, de l'authentification du serveur à la protection de l'homme du milieu en passant par la protection contre les attaques de relecture, est géré automatiquement par TLS à une couche même pas vue par le programmeur de haut niveau moyen. Dans votre situation, vous indiquez que vous ne pouvez pas utiliser les connexions TLS / (SSL) réelles, ce qui est malheureux. Mais je tiens à préciser que je déconseille vivement toute implémentation personnalisée conçue pour remplacer TLS.

Potentiellement en dernier recours, car il ne sera pas aussi bon que le TLS de bout en bout ... mais vous pourriez peut-être mettre quelque chose comme CloudFlare devant pour au moins avez TLS vers le point de terminaison client?

Une autre option est d'écrire un plugin de navigateur, ou un script Tampermonkey (pour réduire les maux de tête multi-plateforme), et d'avoir le code JS pré-livré au navigateur. Je le mentionne uniquement à titre de mesure de dernier recours.

L'inconvénient évident est que vos utilisateurs sont limités à utiliser les ordinateurs qui ont déjà le plugin, ou à devoir le télécharger à nouveau chaque fois qu'ils utilisent un nouvel appareil . Il serait également difficile d'utiliser des appareils mobiles avec.