Arrêtez de masquer les mots de passe !

Le fait de devoir ou non masquer les mots de passe divise les spécialistes. Ne serait-ce que pour des raisons de confidentialité et de sécurité, il semble pourtant nécessaire de devoir les masquer.

Le dernier Alertbox de Jakob Nielsen Stop Password Masking a provoqué pas mal de discussions. 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 semble oublier ou passer sous silence un certain nombre de problématiques qui rendent sa position caduque. La dissimulation des mots de passe semble au contraire indispensable, bien que les implémentations doivent aujourd'hui être totalement changées. 

Une double question de sécurité

Le choix d'un mot de passe simple répond à un besoin de mémorisation

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 semble être 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 pour les éviter, les utilisateurs choisissent des mots de passe volontairement simplistes.
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 du type nom de son chien ou 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 sur l'iPhone est peut être la bonne

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.

Article publié par Frédéric de Villamil sous licence Creative Commons sur le blog Ergonomie web, Ruby on Rails et Architecture de l'information