Quelles sont les règles à suivre pour concevoir un bon système d'authentification ?

Un architecte de Google propose une liste de 12 bonnes pratiques

Lorsque vous développez une application qui doit se connecter à un serveur d’authentification pour permettre aux utilisateurs d’accéder à un certain nombre de fonctionnalités, bien mettre en œuvre les règles de gestion des comptes, d’autorisation et de mots de passe est une tâche très complexe pour les développeurs. En plus de devoir être sécurisé, un bon système d’authentification devra être utilisable et évolutif. Pour parvenir à intégrer toutes ces contraintes dans un système d’authentification de compte, Ian Maddox, GCP Solutions Architect chez Google, propose 12 règles qu’il présente comme les bonnes pratiques pour s’assurer d’avoir un système d’authentification de compte sûr, évolutif et utilisable.

1.Le hachage des mots de passe

Selon Maddox, la règle la plus importante en matière de gestion de comptes « est de stocker en toute sécurité les informations sensibles des utilisateurs, y compris leur mot de passe ». Pour l’architecte, ces informations sensibles doivent être considérées comme sacrées, et par conséquent doivent être gérées de manière appropriée.

En raison de leur sensibilité, l’architecte de Google recommande de ne jamais stocker des mots de passe en clair. Ce qu’il convient plutôt de faire, c’est hacher ces mots de passe avec des fonctions impossible à inverser et stocker leurs valeurs dans une base. Cela peut se faire en utilisant des fonctions de dérivation de clés comme PBKDF2, Argon2, Scrypt, ou encore Bcrypt. Par ailleurs, Maddox recommande de ne jamais utiliser des technologies de hachage obsolètes telles que MD5, SHA1 et en aucun cas le développeur ne doit utiliser un chiffrement réversible ou chercher à inventer son propre algorithme de hachage. Et pour ajouter une couche supplémentaire de sécurité, il préconise également d’appliquer un salage aléatoire à la valeur de hachage de chaque mot de passe d’utilisateur.

Pour Maddox, lorsque le développeur conçoit son système d’authentification, il doit supposer qu’il sera éventuellement compromis. Aussi doit-il se poser des questions comme le fait que, « si ma base de données était exfiltrée aujourd’hui, la sécurité de mes utilisateurs serait-elle en péril sur mon service ou d’autres services qu’ils utilisent ? Que pouvons-nous faire pour réduire les risques de dommages en cas de fuite ? » En tentant d’apporter des réponses à ces questions, les développeurs renforceraient la sécurité de leur système et éviteraient d’exposer les données sensibles de leurs utilisateurs.

Enfin, l’architecte souligne sur ce premier point que si vous êtes à même de produire le mot de passe d’un utilisateur en texte clair après qu’il été créé, cela suppose qu’il y a certainement un problème avec votre implémentation.

2.Autoriser les fournisseurs d’identité tiers si possible

Les fournisseurs d’identité tiers sont des entités extérieures qui vous permettent de vous fier à un service externe de confiance pour authentifier l’identité d’un utilisateur. Google, Facebook et Twitter sont des fournisseurs couramment utilisés qui peuvent être utilisés pour authentifier un utilisateur. À côté de cette solution, Maddox met en avant le fait que le développeur peut implémenter des fournisseurs d’identité externes à côté de son système d’authentification interne existant en utilisant une plateforme telle que Firebase Auth ou toute autre plateforme qui a déjà fait ses preuves.

3.Séparer le concept d’identité de l’utilisateur et le compte d’utilisateur

Selon Maddox, un système de gestion de comptes d’utilisateurs bien conçu a un faible couplage et une forte cohésion entre les différentes parties du profil d’un utilisateur. Pour mieux comprendre ce concept, l’architecte explique qu’il faut faire un distinguo entre les utilisateurs et les adresses e-mail. Pour lui, les utilisateurs ne sont ni un numéro de téléphone ni un identifiant unique fourni par une réponse OAUTH. Les utilisateurs sont et devraient être l’aboutissement de leurs données et de leur expérience uniques et personnalisées au sein de votre service.

Il serait donc utile de séparer les concepts de compte d’utilisateur et d’informations d’identification. En agissant ainsi, cela donnera la possibilité aux utilisateurs de modifier leur nom d’utilisateur et de lier plusieurs identités à un compte d’utilisateur unique. De manière plus concrète, Maddox recommande d’avoir un identifiant global interne pour chaque utilisateur et de lier son profil et son identité d’authentification via cet identifiant, plutôt que de les empiler dans un seul enregistrement.

4.Autoriser la liaison de plusieurs identités à un seul compte d’utilisateur

Pour diverses raisons, un utilisateur peut vouloir créer plusieurs identités sur une plateforme donnée afin de faire par exemple la séparation entre ses différentes activités. Mais pour ne pas se disperser, ce dernier pourrait vouloir les regrouper sous un seul compte. En principe, si le développeur a bien respecté le principe de séparation de l’identité de l’utilisateur et l’authentification comme édicté par Maddox, alors cela s’avèrera plutôt facile de lier plusieurs identités à un seul utilisateur. Pour ce faire, le développeur pourrait demander à l’utilisateur de fournir un détail d’identification commun, tel que l’adresse e-mail, le téléphone ou le nom d’utilisateur. Si ces données correspondent à un utilisateur existant dans le système mis en place, l’on pourrait lui demander de s’authentifier auprès d’un fournisseur d’identité tiers connu et de lier le nouvel ID à son compte existant.

5.Ne pas bloquer...