La publication de HTTP vers HTTPS est-elle une mauvaise pratique?
En supposant que SSL sert à la fois à chiffrer les données et pour fournir une assurance quant à l'identité et à la légitimité du site Web, la pratique consistant à fournir un formulaire de connexion sur une page demandée via HTTP devrait-elle être évitée, même lorsqu'elle est publiée sur HTTPS?
La question concerne un post que j'ai fait hier sur le Who's who des mauvaises pratiques de mot de passe et certains des commentaires suggérant que ne pas voir visiblement le certificat représenté dans le navigateur avant l'authentification était bien si en effet le formulaire posté en toute sécurité .
À mon avis, cela vend SSL à court, car vous perdez non seulement la possibilité de valider la légitimité du site avant de remettre vos informations d'identification, mais vous n'avez également aucune certitude qu'il l'est publication via HTTPS. Je suis conscient que Twitter et Facebook adoptent cette approche, mais le devraient-ils? Suis-je en train d'oublier quelque chose ici ou est-ce une pratique qui devrait être découragée?
Mise à jour: J'ai fini par détailler le résultat de cette question et la discussion qui a suivi dans le billet de blog SSL ne concerne pas le cryptage
OWASP déclare:
(copié textuellement de http://www.owasp.org/index.php/SSL_Best_Practices )
Pages de connexion sécurisées
Il existe plusieurs considérations importantes pour la conception sécurisée d'une page de connexion. Le texte suivant abordera les considérations concernant SSL.Les connexions doivent être publiées sur une page SSL C'est assez évident. Le nom d'utilisateur et le mot de passe doivent être publiés via une connexion SSL. Si vous regardez l'élément action du formulaire, il doit s'agir de https.
La page de destination de connexion doit utiliser SSL La page réelle où l'utilisateur remplit le formulaire doit être une page HTTPS. Si ce n'est pas le cas, un attaquant pourrait modifier la page telle qu'elle est envoyée à l'utilisateur et changer l'emplacement de soumission du formulaire ou insérer du code JavaScript qui vole le nom d'utilisateur/mot de passe lors de la frappe.
Il ne doit y avoir aucun message d'erreur ou d'avertissement SSL La présence d'un message d'avertissement SSL est un échec. Certains de ces messages d'erreur sont des problèmes de sécurité légitimes; d'autres désensibilisent les utilisateurs contre de réels problèmes de sécurité car ils cliquent aveuglément sur accepter. La présence de tout message d'erreur SSL est inacceptable - même une incompatibilité de nom de domaine pour le www.
Les connexions HTTP doivent être supprimées Si un utilisateur tente de se connecter à la version HTTP de la page de connexion, la connexion doit être refusée. Une stratégie consiste à rediriger automatiquement les connexions HTTP vers les connexions HTTPS. Bien que cela amène l'utilisateur à la page sécurisée, il existe un risque persistant. Un attaquant exécutant un homme dans l'attaque du milieu pourrait intercepter la réponse de redirection HTTP et envoyer l'utilisateur vers une autre page.
Pour répéter: La page de destination de connexion doit utiliser SSL
Il peut être utile d'ajouter qu'il existe outils automatisés pour faire exactement ce que les meilleures pratiques OWASP indiquent: "un attaquant pourrait modifier la page telle qu'elle est envoyée à l'utilisateur et changer l'emplacement de soumission du formulaire ... "Le lien inclut une présentation de Black Hat sur l'attaque.
Pour compléter les réponses déjà fournies. Il y a eu des cas pratiques où la présence de pages de destination non HTTPS permet aux attaquants de modifier le site et de récupérer les informations d'identification des utilisateurs. Cet exemple , est le plus récent que j'ai vu. Dans ce cas, cela a été fait au niveau du FAI, mais cela pourrait également être fait par des fournisseurs de points d'accès sans fil ou toute personne utilisant les outils appropriés pour mener une attaque Man-In-The-Middle.