8 Jan, 2020

L’authentification : bonnes pratiques et UX

Comment bien gérer tout ce qui entoure la création d'un compte utilisateur, identifiant, mot de passe, mot de passe oublié, sécurité, bonnes pratiques et expérience utiisateur.

Tout système informatique, web, mobile, bureaux, etc., s’il manipule des données est composé d’un système d’authentification, par lequel les utilisateurs pourront se connecter pour accéder à des fonctionnalités ou des informations qui leur sont propres.

Ces systèmes d’authentification sont sources de beaucoup de réflexion et évolutions, notamment autour de la question du mot de passe, de sa complexité, de sa sauvegarde de manière cryptée, etc.

Nous vous proposons dans cet article un passage en revue de tout ce qui, à notre sens, doit ou peut être mis en place autour d’un système d’authentification, aussi bien pour apporter une expérience utilisateur agréable que pour assurer une bonne sécurité des interfaces et des données.

Création d’un compte par l’utilisateur

A la création d’un compte, on demandera à l’utilisateur de créer un « couple de sécurité » pour pouvoir l’authentifier par la suite. Il est question donc de créer un « identifiant » et un « mot de passe ».

L’identifiant

La norme actuelle est d’utiliser une adresse mail comme identifiant. En effet, c’est la méthode utilisée pour un grand nombre de systèmes. Contrairement à un pseudo, l’adresse mail est propre à l’utilisateur, est unique et est mémorisée facilement par l’utilisateur. Même un utilisateur très friand de technologies n’aura pas plus de 2 à 4 adresses mails en sa possession qu’il utilise pour créer des comptes. Comme on lui demandera par la suite de définir et mémoriser un mot de passe, pas la peine de le contraindre à retenir un pseudo ou un identifiant supplémentaire. Si votre système nécessite tout de même ce genre d’informations, pas de soucis, cette information pourra être complétée sitôt le compte créé.

Le mot de passe

Le débat fait rage ici, entre la longueur minimale et le type de caractères qu’il doit contenir. Nous proposons donc l’ensemble de critères suivants :
– nombre de caractères minimum : 6
– présence obligatoire : minuscule, majuscule, chiffres

On pourrait rajouter des caractères spéciaux, mais la vraie nécessité est de protéger votre application contre une attaque de type « brute force », qui permet de tester un grand nombre de combinaisons de mot de passe de manière automatisée et très rapide. Nous y reviendrons dans la gestion des erreurs liées à l’authentification.

Autre chose importante à tester, la liste des mots de passe les plus utilisées. Chaque année sort un classement des 100 mots de passe les plus utilisés par les gens : « azerty », « 123456789 », « soleil », « starwars », etc. Cette liste est accessible facilement. Et il n’est pas très complexe de programmer leur interdiction d’utilisation dans votre application.

Dans le même genre, pour s’assurer que le mot de passe ne peut pas être facilement deviné par une personne mal intentionnée, on peut s’assurer que le mot de passe ne contient pas d’informations que l’on retrouve dans l’adresse mail. Si l’adresse mail est prenom.nom@domaine.com, on peut isoler prenom et nom et vérifier s’ils sont dans le mot de passe et donc demander à l’utilisateur de définir un mot de passe différent. Attention à bien tester des mots qui font 3 à 4 caractères minimum.

Enfin, vous pouvez apporter une indication textuelle à l’utilisateur sur ces bonnes pratiques, en rajoutant par exemple de ne pas utiliser un mot de passe déjà utilisé sur une autre plateforme ou en lui suggérant d’utiliser un gestionnaire de mot de passe, qui créera automatiquement un mot de passe aléatoire et le sauvegardera de manière sécurisée.

Création d’un compte par l’administrateur

Aparté technique, les mots de passe doivent être enregistrés de manière cryptées dans une base de données. C’est une obligation légale, encore plus forte depuis la mise en place du RGPD. Ils ne sont donc jamais accessibles en lecture, que ce soit en base de données, ou dans un mail ou un chat par exemple.

Cela signifie que lorsque vous créez un compte pour un utilisateur, vous n’êtes pas censé générer son mot de passe vous même, sinon cela signifie que vous le connaissez et que vous serez obligé de lui transmettre, par exemple par mail, en clair. Le mot de passe pourrait être créé aléatoirement et envoyé par mail à l’utilisateur pour sa première connexion, mais de la même manière, celui-ci se retrouve donc en clair, dans le mail. Si l’utilisateur se fait pirater sa boite mail, le mot de passe sera accessible en clair et utilisable facilement.

Pour éviter cela, 2 méthodes :
La création d’un mot de passe temporaire, fonctionnel sur une période courte, et ou limité dans le nombre d’utilisations. Dès que l’utilisateur se connecte par ce mot de passe, il est invité à le mettre à jour. Au bout d’un moment, celui-ci ne fonctionne plus.
Envoyer un mail à la création du compte, invitant à finaliser l’inscription. Dans ce cas, la création du compte faite par un administrateur n’est qu’une première étape, l’utilisateur devra lui même finaliser le process par la création de son mot de passe. Un mail automatisé lui est donc transmis, contenant un token d’accès limité également dans le temps (voir plus loin la partie dédiée aux tokens).

Erreur à la connexion

Lorsqu’un utilisateur va tenter de se connecter et que le process échoue, la bonne pratique est de lui indiquer un message d’erreur, lui expliquant ce qu’il s’est passé et l’invitant à recommencer. Il est par contre nécessaire de ne pas différencier les messages d’erreur, ce qui n’est pas toujours le cas.

On retrouve souvent 2 types de messages d’erreur :

L’adresse mail est inconnue.

Le mot de passe est incorrect

Il est donc différencié l’erreur sur l’identifiant de l’erreur sur le mot de passe.

Le problème avec cette pratique est que cela donne une information très intéressante pour une personne mal intentionnée. Si je prends un site ou une application et que j’essaye de me connecter avec l’adresse mail de la personne que je cherche à piratée, si le message d’erreur porte sur le mot de passe précisément, cela m’informe que cette personne possède bel et bien un compte sur cette application.

Si le message est toujours identique :

La connexion a échouée, merci de réessayer

Il devient impossible de savoir si le problème vient du mot de passe et ou de l’identifiant. De cette manière, on sécurise une information capitale de l’application !

Ces recommandations s’appliquent également pour le « mot de passe oublié ».

Brute force et multiples tentatives

Pour éviter le piratage, il est important de limiter le nombre de tentatives de connexion. Tout d’abord en s’assurant que les tentatives de connexion sont bien effectuées depuis le formulaire de connexion, et non de manière distante. Et donc de bloquer, par exemple au bout de 3 à 5 tentatives de connexion, pour un temps donné. Par exemple, après 5 tentatives échouées, on peut bloquer la connexion pour ce compte donné durant 5 min. Cela suffira amplement à décourager tous les scripts de brute force, qui consistent à tester tous les mots de passe possibles pour trouver le bon. Pour un mot de passe de 8 caractères composées de minuscules, majuscules et de chiffres, le nombre de possibilités est de (26+26+10)^6, soit plus de 56 milliards de possibilité… et plus de 100.000 ans pour tout tester.

Mot de passe oublié

Lorsqu’un utilisateur oublie ou égare son mot de passe, il est intéressant de lui proposer un processus de récupération automatisé, de manière à ce qu’il n’y ait pas besoin d’intervention humaine directe pour réinitialiser son mot de passe.

Attention, ce process n’est pas à réaliser dans 100% des cas ou pour 100% des comptes utilisateurs. Vous pouvez tout à fait avoir des niveaux d’utilisateur qui requièrent une sécurité du mot de passe plus importante, et donc sortir ces utilisateurs de cette possibilité de récupération automatisée.

La récupération automatisée du mot de passe consistera à envoyer un mail à l’utilisateur qui aura donc saisi son adresse mail préalablement. Comme expliqué dans le point précédent, un seul message à apporter à l’utilisateur :

N

Merci de consulter la boite mail renseignée pour récupérer votre mot de passe

A adapté comme vous le souhaitez mais ne pas indiquer :

Cette adresse mail n’existe pas dans notre système

Pour reprendre le point 2, on ne créera pas le mot de passe automatiquement pour le transmettre par mail, ce sera à l’utilisateur de réaliser l’opération. Pour cela, le mail expédié contiendra un token, permettant de réaliser cette opération.

Tokens

Un token ou jeton est une clé aléatoire longue qui permet de sécuriser une action sensible. Un peu comme si on créait un mot de passe unique dédié à la réalisation d’une tâche précise, avec une utilisation limité en nombre et en temps.

Exemple d’un token : vzrEZ51Bz2eIze27oho83fubz349zZEze235KNFDq464iuhzo

Voici dans une base de données ce à quoi cela pourrait ressembler :

Selon l’action à réaliser, on va donc créer un token assigné à un utilisateur et dédié à une action. On limitera également en nombre d’execution et dans le temps. Par exemple, pour la mise à jour d’un mot de passe, on peut limiter le token à 1 seule utilisation, pour une validité d’1 heure. L’idée étant que l’utilisateur mette à jour son mot de passe dans la foulée de sa demande et non plus tard. Sinon, il doit réaliser une nouvelle demande.

Ce système de tokens peut permettre également de forcer la connexion d’un utilisateur. Si une application envoie une notification par mail à l’utilisateur l’incitant à réaliser une action importante. Pour faciliter le process, la boite mail faisant office de sécurité, les liens contenus dans le mail peuvent contenir un token qui permettra de connecter automatiquement l’utilisateur et de le rediriger spécifiquement vers l’action à réaliser. On améliore l’expérience utilisateur en ne repassant par l’étape préalable de l’authentification.

Sauvegarde de la connexion dans les cookies

Il est très courant aujourd’hui de proposer à l’utilisateur de mémoriser sa connexion par un système de cookies. Il faut systématiquement demander la permission à l’utilisateur de réaliser cette mémorisation, par une case à cocher du genre « Se souvenir de moi » ou « maintenir la connexion sur cet ordinateur ».

Cette sauvegarde doit avoir une durée de vie, qui doit aujourd’hui être communiquée à l’utilisateur dans le cadre du RGPD. Selon votre application, et la sensibilité on peut imaginer une persistence de connexion par cookies allant de 24h à plusieurs mois.

Encore une fois, ce n’est pas une obligation, une application très sensible peut contraindre l’utilisateur à saisir son mot de passe à chaque fois par mesure de sécurité.

Sécurité supplémentaire

On l’a vu à plusieurs reprises, on se base sur des mails et des tokens pour accéder à l’authentification, la boite mail faisant donc foi pour la sécurité de l’application. Le risque avec cette confiance absolue dans la boite est que le piratage de la boite mail permet alors de pirater l’ensemble des applications auxquelles l’utilisateur a déjà accédé. Si la boite mail est ouverte, il lui suffit alors de renseigner le mail dans la fonctionnalité « mot de passe oublié » pour récupérer l’accès sans aucune difficulté.

C’est pourquoi on peut rajouter une étape supplémentaire de vérification.

La méthode désuète

La méthode désuète : la question secrète. « Le nom de jeune fille de votre mère », « le nom de votre animal de compagnie quand vous étiez enfant », ou encore « votre destination de vacances favorite ». Soit la question n’est pas si secrète que ça et en fait l’attaquant connait sans doute lui aussi la réponse (ou peut la retrouver en 2 clics sur les réseaux sociaux) soit la question secrète est tellement « compliquée » que vous ne vous souvenez plus de la réponse que vous avez vous même donné au moment où vous l’avez renseigné et vous avez alors vous même bloqué votre compte.

La méthode correcte

La méthode correcte : l’envoi d’un code unique par SMS. A la manière d’un token, on crée un code de vérification : 4 à 6 caractères à saisir par l’utilisateur pour réinitialiser son mot de passe par exemple. Le code ayant préalablement été envoyé sur le téléphone portable. Cela nécessite par contre de posséder le numéro de portable de votre utilisateur, ce qui n’est pas toujours nécessaire. Par contre, cela peut être une option de sécurité proposée pour ceux qui souhaitent sécuriser davantage leur accès et qui sont donc dans l’obligation dans renseigner leur numéro de téléphone à cette fin.

Cette méthode de sécurité, à la manière de ce qui se fait dans le domaine bancaire, peut être appliqué à d’autres endroits que la récupération du mot de passe, que ce soit à la connexion, ou lors de l’execution d’une action sensible.

Des outils tiers peuvent également être utilisés, comme Google Authenticator qui envoie un code unique valable sur une période de temps très courte.

Et si on me vole mon téléphone, avec un accès à mes mails dessus ?

Les 2 systèmes précédents deviennent donc désuets. Seule solution, le temps ! La réinitialisation du mot de passe, sécurisée par un token dans un mail puis validée par un code SMS ne sera exécutée ou effective qu’au bout de, par exemple, 24h. Dans ce cas là, on peut imaginer que la personne piratée a le temps de s’en rendre compte et donc de prévenir le ou les services concernés pour bloquer ces comptes en amont.

Conclusion

  • On définit la dureté du mot de passe et on informe bien l’utilisateur lors de la saisie
  • On fait attention aux messages d’erreur
  • On ne transmet jamais un mot de passe, le système permet à l’utilisateur de le créer, modifier
  • On définit une durée de vie aux tokens
  • La double authentification peut permettre d’ajouter une couche de protection supplémentaire et ou de sécuriser davantage certaines actions sensibles.

Aller + loin…

A la création d’un compte, on peut être confronté également au problème d’indiquer ou non à l’utilisateur si l’adresse mail renseignée existe déjà ou non et donc contourner la transparence mise en place à la connexion et pour la récupération du mot de passe.

Dans ce cas là, on peut avoir un process identique, qui consiste à créer le compte, s’il n’existe pas déjà et à inviter l’utilisateur à consulter ses mails pour finaliser le process d’inscription. C’est un token contenu dans le mail qui permettra de poursuivre l’inscription. Le message affiché à l’utilisateur restera donc neutre, du genre :

N
Consultez votre boite mail pour poursuivre l’inscription.

Si un compte existe déjà pour cette adresse mail, on peut alors envoyer un mail différent du genre : « Attention, vous cherchez à créer un compte qui existe déjà » en expliquant de passer plutôt par la fonctionnalité de mot de passe oublié.

De la même manière, on peut envoyer un mail de contrôle lors de la réalisation d’une action sensible. Pour permettre à l’utilisateur d’agir rapidement si cette action a été réalisée à son insu.

#authentification #UX