Renifler les informations d'identification de l'utilisateur wordpress
En ce qui concerne le développement WordPress après un développement plus "hardcore" (lent), je trouve extrêmement étrange que le processus de connexion WordPress ne fournisse absolument aucune défense contre le reniflement des données d'identification.
Tout cela est écrit en texte clair, ce qui facilite extrêmement l'exploitation des informations d'identification de connexion de n'importe qui sous un réseau WiFi public, y compris les administrateurs, si le site Web ne dispose pas de protocole SSL.
Même la recherche de plugins susceptibles de chiffrer les données avant de les envoyer au serveur a été vaine.
Alors quoi de neuf WordPress? Est-ce une bonne pratique d'installer SSL sur tous les sites Web? Est-il considéré OK de simplement vous connecter avec votre compte administrateur sur un réseau WiFi public, que SSL soit installé sur votre site Web? Et qu'en est-il du processus de connexion/enregistrement des autres utilisateurs? Il semble que la plupart des sites Web WordPress et leurs utilisateurs soient exposés à un risque de sécurité majeur, à moins d'utiliser le cryptage SSL.
Le processus de connexion lui-même n’est pas aussi important, c’est une chose que vous pouvez faire une fois par an avec les bons paramètres.
Ce qui est important, ce sont les cookies d'authentification qui sont envoyés. Tant qu'ils ne sont pas cryptés, peu importe le niveau de défense que vous mettez sur le formulaire de connexion lui-même, et les cookies sont envoyés à chaque fois qu'une des URL du site est récupérée.
Donc, soit vous avez SSL ou vous n'êtes pas sécurisé. Il existe un moyen terme dans wordpress dans lequel vous obtiendrez automatiquement les URL HTTPS des utilisateurs connectés (et le formulaire de connexion), mais vous aurez évidemment besoin d'un certificat.
Pourquoi personne n'utiliserait-il le protocole HTTPS alors que la menace du WiFi est connue et que le coût d'un certificat est nul? parce que le coût du certificat "gratuit" est une perte de temps pour le configurer et l'administrer. Bien que la menace WiFi existe, personne ne lui a montré qu'utiliser le WiFi est moins sécurisé que d'avoir un compte sur Yahoo et que la plupart des gens ne se connectent pas un Wifi externe à leurs sites. Personnellement, j'utilise mes données cellulaires même lorsque le WiFi gratuit est disponible.
Il est également avantageux de ne pas exécuter un site HTTPS complet, en particulier la mise en cache. Lorsque vous utilisez HTTPS, votre contenu ne peut pas être mis en cache.
Alors oui, l'industrie (google) essaie d'en faire un blanc et un noir, mais en réalité, elle est (comme la plupart des choses) grise. Chacun doit évaluer ses propres risques de sécurité et les comparer à la quantité de travail nécessaire pour les surmonter et prendre sa propre décision.
En plus de la réponse de @ MarkKaplun qui répond à la vraie question, j'ai pensé ajouter le point de vue du pirate informatique dans le sujet. Je ne suis pas un "expert" de la sécurité, mais j'ai une certaine expérience dans ce domaine. Laisse-moi expliquer.
Si je commettais une attaque MiTM sur le réseau où se trouvent lesdits utilisateurs, je commencerais par examiner les paquets non SSL, qui ne sont pas cryptés. Supposons maintenant que je trouve une clé de formulaire pour laquelle je trouve également une valeur altérée. Ma première intuition serait de chercher le référant, d'aller au référent et d'inverser le code JS qui le fait.
Vous pouvez évidemment me tromper avec les applications flash/Java, mais vous ne le ferez pas vraiment car cela effrayerait vos visiteurs (à moins que vous n'ayez quelque chose de privé, non?).
Même si vous activez SSL sur la page de connexion, j'essayerais de faire accepter mon faux certificat par l'utilisateur. Cela entraînera une divulgation complète des informations de ce client.
Le fait est que SSL et une stratégie de connexion très stricte sont activés au lieu d’un formulaire chiffré, car vous ne pouvez pas le chiffrer en fin de compte côté client. Si votre utilisateur est un ******, il/elle continuera à l'être.
Avertissement: Prenez tout cela avec une pincée de sel car je ne suis pas un expert en sécurité.
Tout cela n’est pas différent pour WP que pour tout le reste. Si vous n'utilisez pas le protocole SSL, tous ceux qui peuvent intercepter le trafic peuvent capturer tout ce qui est transmis. Vous pouvez soit obtenir SSL ou vivre avec le risque. Donc, ceci est probablement hors sujet ici de toute façon car il n'est pas spécifique à WP.
Votre idée de chiffrer avant le transfert - je ne comprends pas vraiment. Sauf si vous utilisez un plug-in de navigateur qui gère cela, le code qui pourrait chiffrer le mot de passe provient d'un serveur auquel vous ne pouvez faire confiance. Un attaquant devrait donc vous envoyer un JS manipulé qui laisse filtrer le mot de passe au lieu d'écouter simplement le trafic. Peut-être un peu plus difficile, mais reste fondamentalement le même.
TLDR; Si vous voulez que votre site soit sécurisé, obtenez SSL. Sinon, respectez les risques ou évitez au moins les réseaux hostiles (par exemple, le wifi public).