Mots de passe non sécurisés

Page MDN sur les Mots de passe non sécurisés

 

Le protocole HTTPS est conçu de telle sorte que les données utilisateurs soient protégés de l'espionnage (faille pour la confidentialité des données) et de la modification (faille pour l'intégrité des données) sur le réseau. Les sites web qui traitent les données utilisateurs devraient utiliser HTTPS pour protéger leurs utilisateurs des hackers. Sans cela, il est très facile de voler des informations sur les utilisateurs (comme leurs identifiants). Ceci a été démontré largement par Firesheep.

 

Fournir des formulaires d'identification non sécurisés est dangereux, en particulier du fait de la large variété d'attaques qui peuvent être utilisés contre eux. Ceux qui espionnent le Web volent les identifiants d'un utilisateur directement en analysant le réseau, ou en modifiant la page donnée en transit pour mettre en place une grande quantité d'attaques.

 

Le panneau de sécurité sur la Console web de Firefox alerte les développeurs s'ils fournissent des pages qui demandent des mots de passe, comme des formulaires d'identification, via une connexion non sécurisée. Il y a plusieurs scénarios dans lesquels un développeur Web peut mettre à mal la protection des identifiants des utilisateurs  :

 

1. Fournir un formulaire d'identification via HTTP. Même si le paramètre action du formulaire renvoie à une URL HTTPS, le formulaire d'identification de l'utilisateur n'est pas protégé car un hacker peut modifier la page reçue par l'utilisateur (par exemple, les pirates peuvent insérer un script de « keylogging » qui extrait son mot de passe au cours de la saisie, ou encore changer la destination du formulaire pour envoyer les données sensibles sur un serveur qu'ils contrôlent). Voici une copie d'écran montrant les messages d'alerte affichés dans l'onglet sécurité de la console web :

 

 

2. Utiliser une URL HTTP dans le paramètre action du formulaire. Dans ce cas, toutes les données que l'utilisateur saisit sont envoyées via le réseau en clair. Le mot de passe de l'utilisateur est visible clairement par n'importe qui analysant le réseau entre le moment ou le mot de passe commence son transit depuis l'ordinateur de l'utilisateur jusqu'au moment où il arrive sur le serveur web du site. Voici une autre copie d'écran qui présente le code source HTML du formulaire et le message d'alerte qui en découle :

 

3. Fournir le formulaire d'identification dans une iframe HTTP (ou une frame HTTP qui est embarquée dans une frame HTTP). Même si la plus haute page est HTTPS, inclure le champ mot de passe dans une frame HTTP est équivalent à l'inclure dans une page HTTP. Les pirates malfaisants peuvent modifier la page et voler les identifiants utilisateur.

 

Quelquefois les sites web demandent des identifiants, mais ne stockent pas les données très sensibles. Par exemple, un site web d'informations pourrait sauvegarder l'information décrivant quels articles il est probable qu'un utilisateurs veuille relire, mais ne pas sauvegarder d'autres informations à propos de l'utilisateur. Les développeurs web du site pourraient ne pas être assez motivés pour sécuriser leur site et les identifiants de leurs utilisateurs. Malheureusement, la réutilisation des mots de passe est un vrai problème. Les utilisateurs emploient le même mot de passe sur des sites multiples (sites d'informations, réseaux sociaux, boites mails, banques). Et par conséquent, même si l'accès au nom d'utilisateur ou au mot de passe sur votre site ne représente pas un énorme risque pour vous, c'est un gros risque pour les utilisateurs qui ont utilisé le même nom d'utilisateur et mot de passe pour se connecter sur leur compte bancaire. Les pirates sont de plus en plus astucieux, ils volent les paires noms d'utilisateur/mot de passe sur un site et essaient de les réutiliser sur des sites plus lucratifs.