Arrêtez de masquer les mots de passe !

Le dernier Alertbox de Jakob Nielsen Stop Password Masking a provoqué pas mal de discussions, certains n’hésitant pas à le qualifier de plus grand ramassis de conneries qui ait jamais été publié sur Internet. Nielsen y explique que les erreurs dues à l’obfuscation des mots de passe dans les champs de saisie entraînent la frustration des utilisateurs, et une perte en termes de business pour l’auteur du site.
Sans entrer en totale opposition avec Nielsen, son article me semble oublier ou passer sous silence un certain nombre de problématiques qui rendent sa position caduque. La dissimulation des mots de passe me semble au contraire indispensable, bien que les implémentations doivent aujourd’hui être totalement changées.

Une double question de sécurité

Le masquage des mots de passe dans les champs de saisie s’impose d’abord pour une question de confidentialité. Les ordinateurs sont de plus en plus souvent utilisés dans un contexte de mobilité : clientèle, aéroport, lieux publics dans lesquels peut tout à fait se trouver des caméras de surveillance. L’affichage des mots de passe en clair à l’écran fait donc courir un risque non négligeable de récupération des données. Si Nielsen n’oublie pas ce point, qu’il traite en deux lignes ajoutant que l’utilisabilité doit parfois passer après la sécurité, l’idée d’un champs password à l’obfuscation débrayable me semble un cataplasme aussi hâtif que contre productif.

Nielsen met en avant le fait que masquer les mots de passe entraîne des erreurs, et que, afin d’éviter les erreurs, les utilisateurs choisissent des mots de passe volontairement simplistes. C’est, pour le coup, une des plus grosses conneries que j’ai pu lire depuis que je suis sur le web, à égalité peut-être avec e Telnet, ca prends combien de raw sockets en sur-adressage sur un FDDI ?, mais c’était de l’humour.
Le choix d’un mot de passe simple répond à un besoin de mémorisation. Il est plus simple de se souvenir d’un mot de passe simple, ou d’un élément familier toto, nom de son chien, date de naissance… que d’une chaîne de 10 caractères générée aléatoirement mélangeant lettres majuscules et minuscules, chiffres et caractères spéciaux.

Le nécessaire masquage des mots de passe dans les zones de saisie correspond également à un besoin de sécurité côté utilisateur. Tout comme la réaction naturelle est de s’attendre à ce que valider un formulaire force le rechargement de la page – et ce même si toutes les données sont envoyées en AJAX – l’utilisateur s’attend à ce qu’un tiers ne puisse pas voir son mot de passe, même si ce dernier est écrit en clair sur un post-it collé à son écran.

Une nouvelle implémentation nécessaire

Nielsen a en revanche raison sur un point important : l’implémentation des champs de type password y compris sur les navigateurs modernes n’est pas adapté à l’évolution des usages, et particulièrement à celui de la mobilité. La taille des claviers, l’utilisation d’une même touche pour gérer plusieurs caractères, ou les claviers tactiles rendent délicate la frappe d’un mot de passe complexe en aveugle.

Obfuscation des mots de passe sur l'iPhone

La méthode mise en place par Apple (et peut-être d’autres) sur l’iPhone depuis la version 2.0 de son OS est peut-être la réponse la plus adéquate au problème du masquage des mots de passe. Chaque caractère entré s’affiche en clair à l’écran durant une seconde avant d’être caché. Dans un contexte de mobilité, cela assure à l’utilisateur la relecture de son mot de passe tout en en conservant la confidentialité d’un bout à l’autre du processus de saisie.

La mise en place d’un tel procédé est du ressort des éditeurs de navigateurs, puisqu’il s’agit de redéfinir le comportement du champs de type password. Une implémentation partielle utilisant Javascript me semble possible, mais limitée à quelques navigateurs, seulement pour le processus de saisie initiale, et non accessible. Sa mise en place en édition est en revanche à repousser aux calendes grecques.

Publié le 28 juin 2009 à 16h18 Publié sous Ergonomie web et logicielle

Mots clés mot de passe, formulaire, utilisabilité, password

Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.

12 commentaires sur Arrêtez de masquer les mots de passe ! »

Par juytter le 28 juin 2009 à 18h52 :

Je n’ai pas lu l’article orignal, mais ce n’est pas si bête que ça si on considère que « simpliste » veut dire « avec le minimum de caractères requis ». En masquant les caractères, on a mathématiquement plus de chance de faire une erreur de frappe « sans s’en apercevoir » et psychologiquement douter du mot de passe qui était, à priori, le bon. Ça me semble valable pour des utilisateurs qui ne font pas de saisie (clavier) à l’aveugle et qui n’ont pas de “stratégie” organisée de mot de passe pour gérer 15-20 comptes : ahma la grande majorité des utilisateurs.

L’exemple de l’iPhone serait donc pertinent aussi pour le non-mobile.
Par Oncle Tom le 28 juin 2009 à 20h59 :

Cette méthode de masquage progressif sur mobile existait déjà sur les téléphones Nokia … donc largement avant l’OS2 de l’iPhone.

C’est à l’outil d’adapter sa prise en charge des mots de passe … tout virer serait effectivement une connerie monumentale.
Par Ishiro le 28 juin 2009 à 21h59 :

Le meilleur compromis me semble être en effet celui implémenté par l’iPhone… Je le trouve très intéressant.

En revanche je suis assez gêné de taper mes mots de passe dans ces conditions quand il y a du monde autour… Ça doit être mon côté parano.

Je pense qu’il serait quand même intéressant de pouvoir choisir le mode “tout masquer” dans les préférences.
Par Harry Seldon le 28 juin 2009 à 22h54 :

Le mot de passe qui s’affiche par lettre comme sur l’Iphone ou les Nokia ou autre me laisse dubitatif. Comme tu disais, si la scène est filmée le mot de passe entier peut etre volé…
Par Florent V. le 28 juin 2009 à 23h22 :

Il y a un aspect que tu n’abordes pas mais qui me semble intéressant pour critiquer la position de Nielsen. Il s’agit de la perception de sécurité de l’utilisateur, et de l’image véhiculée par un site ou une application qui ne masquerait pas les mots de passe.

Il y a bien sûr des arguments pratiques sur l’intérêt du masquage des caractères saisis dans un champ de mot de passe. Nielsen les écarte en une phrase et évoque un bureau dans lequel on ne va pas venir épier ce que vous tapez. Apparemment Jacob Nielsen n’a pas eu l’occasion de travailler dans un open space. Même quand on a confiance en ses collègues (et on n’a pas toujours cette chance…), autant ne pas leur dévoiler des mots de passe personnels, n’est-ce pas? Les terminaux mobiles et la présence de caméras de surveillance ou d’enregistrement est un aspect que je n’avais pas envisagé, mais ça se rapproche de cet argument.

Mais en plus de cet argument pratique, il y a comme je le disais un argument psychologique. Le masquage du mot de passe, qu’il soit réellement nécessaire ou pas, est perçu comme un gage de sécurité et de fiabilité. Le supprimer, c’est risquer de diminuer la confiance envers un site, une application ou les marques derrière ce site ou cette application.
Par juytter le 29 juin 2009 à 11h30 :

Pour le mode parano, Nielsen en fait déjà la remarque : on peut très bien considérer qu’enregistrer les touches utilisées est aussi “trivial” que d’enregistrer un écran.

Autre point intéressant : le défaut de feedback conditionne (mais à quel point?…) des mots de passes faciles à retrouver y-compris donc pour le pirate. Là encore, le propos me semble juste : le masquage qui offre un gain de sécurité conditionne une perte de sécurité due aux conséquences de la contrainte utilisateur.

Ayant lu l’article de Nielsen, (du coup) je trouve que sa position est assez équilibrée utilisateur/sécurité : masquer par défaut sur des comptes sensibles, ne pas masquer par défaut les autres et offrir en option le masquage avec une checkbox pour rassurer le plus flippé.
Par Eric le 29 juin 2009 à 11h39 :
Je ne suis pas d’accord avec toi Frédéric. Je suis un passionné, ultra connecté, souvent en itinérance. J’ai donc effectivement fréquemment besoin de taper et protéger mes mots de passe.

Pourtant :
- j’ai rarement quelqu’un derrière mon épaule en situation de lire mon écran à ce point. Tout simplement parce que celui qui lit sur mon épaule lit aussi sur mn clavier. J’ai une très bonne vitesse de frappe sur mon mot de passe, mais je suis un informaticien. Monsieur tout le monde tape sur les touches une à une. Celui qui peut voir l’écran a de bonnes chances de lire le mot de passe sur le clavier (surtout que le dit mot de passe est probablement simple à compléter si on manque une ou deux lettres). Le masquage à l’écran est important mais pas tant que ça.
- Je tape encore plus souvent mon mot de passe chez moi, isolé, qu’en situation d’itinérance, bien que je sois déjà un ultra connecté. Monsieur tout le monde doit avoir encore moins d’itinérance.
- Ce qui me préoccupe le plus en itinérance ce n’est pas tellement l’écran mais les spyware quelconque (monsieur tout le monde n’a pas son portable avec lui tout le temps). D’ailleurs regardes ta banque, au final tu cliques sur des chiffres à l’écran et ton voisin de derrière peut trouver ton code avec un peu d’attention. Simplement parce que le risque est faible par rapport aux autres risques.
Alors quoi ? Alors je trouverai très bienvenu des champs en clair pour les mots de passe. La seule contrainte est de pouvoir basculer de “clair” à “masqué” quand j’en ai besoin. Savoir lequel est par défaut est une question simple à résoudre après une bête étude statistique. Ajouter une préférence du navigateur pour les entreprises et les gens qui ont une situation particulière pour avoir besoin du masquage par défaut (genre “je suis en openspace”) et voilà.

Je ne suis pas convaincu par le compromis iphone, qui n’est adapté qu’à ce type de terminal. Ce que fait l’iphone est nécessaire parce que les fautes de frappe y sont plus fréquentes (clavier virtuel). Ce que fait l’iphone est possible parce que l’écran est petit et mobile (peu de chances qu’on t’espionne) mais aussi parce que le clavier est sur l’écran (on voit l’écran quand on tape au clavier, ce qui est le cas d’assez peu de non professionnels).

Moi j’accueille très bien cette remise en question du champ de mot de passe. Avoir un moyen de basculer entre le masquage et la frappe en clair est un besoin réel. Par contre : surtout ne faites PAS ça chez vous. C’est une problématique à traiter par le navigateur et uniquement lui, pas par l’auteur des pages web. Il est important pour le navigateur de savoir que le champ contient une donnée sensible comme un mot de passe, dites le lui, charge à lui de l’afficher de façon adéquate.
Par Thomas Lecavelier le 29 juin 2009 à 14h39 :
Hum… Problématique intéressante.

Cependant je pense qu’on y répond de la mauvaise manière: plutôt que de « patcher » le comportement du navigateur vis à vis de la page web, je tendrais plutôt supprimer l’usage des mots de passes, au profit d’un système décentralisé.

Deux systèmes ont ma préférence:
- OpenId, qui, si bien utilisé (justement décrit par Éric Daspet chez David Larlet) apporte simplicité d’utilisation de l’identité numérique et certitude que la personne l’utilisant est la bonne.
- DIAS Pour les sytèmes plus connectés, qui gagnerais à être plus connu : là, j’avoue que je ne vois pas comment mettre en place un phishing quelconque.
On peut y ajouter l’authentification via certificat privé (PKCS#12) géré merveilleusement bien par tous les navigateurs de la planète, même IE, mais on a un problème de contrainte physique du certificat: il faut le balader de postes en postes ou un générer un par poste… Même problème que pour une clef privée simple dira-t-on.

Bref: l’auth’ via mot de passe… vite, oublions!
Par Soso le 30 juin 2009 à 10h10 :

Tout n’est pas faux dans ce qu’il dit. Cela peut être utile de relire son mot de passe en effet. Je suis personnellement confronté au problème de m’adapter au clavier FR et CH suivant que je sois au travail ou à la maison. Parfois, les doigts vont tout seul sur les touches sans que je ne me rende compte que le clavier a changé :) Mais le pire à mon avis, c’est la UNIX mode qui n’affiche rien du tout quand on tape. Ca, c’est de l’anti-ergonomie…
Par Rubix le 30 juin 2009 à 20h35 :

De l’anti-ergonomie, oui… Il n’empèche, je sais à présent qu’un certain mot de passe de mon chef n’a que quatre caractères. Et ça, c’est de l’anti-sécurité ou je ne m’y connais pas. Même si je ne m’y connais pas, d’ailleurs.
Par Mael le 07 juillet 2009 à 09h20 :

Tout cela est à débattre, certes, mais surtout à vérifier : Nielsen n’avance pas une opinion mais une observation basée sur des tests utilisateurs. Alors bien sûr il a fait du qualitatif, il faudrait faire du quantitatif pour prouver ses dires. Mais faire des tests à grande échelle en situation (cybercafé, bibliothèques, mobiles…) est-il envisageable ? Le mieux est encore de vérifier en comparant les logs de deux versions : une avait passwords clairs et une sans. Il faut juste trouver les cobayes qui acceptent de se faire hacker !

Personnellement j’aime bien la solution de l’Iphone, je pense qu’en utilisant un input simple pour en modifier le comportement on doit pouvoir le faire.
Par Mael le 09 juillet 2009 à 12h22 :

Et hop : http://blog.decaf.de/2009/07/iphone-like-password-fields-using-jquery/