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 les mots de passe longs et complexes
En aout 2017, l’ingénieur du NIST, Bill Burr, qui avait recommandé l’adoption des mots de passe difficiles à retenir (composés d’une une série combinée de chiffres, lettres majuscules et minuscules et de caractères spéciaux) a ouvertement reconnu qu’il regrettait d’avoir avancé ce conseil, car dans la pratique, cela créait plus d’inconvénients aux utilisateurs que cela ne les protégeait. Le NIST qui a repris les travaux de Bill Burr recommande désormais de composer des mots de passe avec des phrases longues et faciles à retenir au lieu de mots de passe courts et difficiles à retenir. Du côté du développeur, l’usage de mots de passe longs par l’utilisateur devrait en principe ne pas poser de problèmes. En effet, vu que la longueur de la valeur de sortie d’un mot de passe haché sera toujours fixe, pour Maddox, les utilisateurs devraient être en mesure d’utiliser des mots de passe aussi longs qu’ils le souhaitent. S’il y a une limite à imposer à l’utilisateur, cela devrait se faire en fonction de la taille maximale du POST autorisée par le serveur et qui est généralement au-dessus de 1 Mo. Enfin, Maddox précise également que le système d’authentification mis en place devrait permettre à l’utilisateur d’utiliser n’importe quel caractère qu’il souhaite comme les Émojis, les espaces, etc.
6.Ne pas imposer de règles déraisonnables pour le choix des noms d’utilisateur
Pour faciliter quelques fois la vie aux développeurs, certains sites préfèrent imposer des restrictions dans la composition des noms d’utilisateur. Certains sites peuvent exiger des noms d’utilisateur de plus de 2 ou 3 caractères. D’autres peuvent bloquer les caractères cachés ou encore empêcher les espaces au début et à la fin du nom choisi. En le faisant, cela facilite la gestion des comptes, mais pourrait également avoir un effet non souhaité d’éloigner certains utilisateurs. Pour Maddox, un site devrait donner la latitude à l’utilisateur de choisir le nom d’utilisateur qu’il désire, tout comme le mot de passe. Toutefois, la meilleure approche recommandée par l’architecte pour éviter des frustrations du côté de l’utilisateur serait d’attribuer des noms d’utilisateur. Et si c’est le cas, il faut s’assurer que le nom attribué est convivial et dénué de symboles visuellement ambigus tels que « ;Il1O0 ;».
7.Permettre aux utilisateurs de changer leur nom d’utilisateur
Dans un bon système de gestion de comptes, les utilisateurs devraient pouvoir changer de nom d’utilisateur à n’importe quel moment sans pour autant être obligé de créer un nouveau compte. Pour cela, le système devrait autoriser l’usage d’alias. Bien entendu, certaines entreprises souhaiteront limiter cet usage afin que cela n’entraine pas des effets pervers. Ainsi, les utilisateurs peuvent être autorisés par exemple à changer leur nom d’utilisateur seulement une fois par an ou encore être empêchés d’afficher autre chose que le nom d’utilisateur principal. Le choix des règles de métier est libre, mais devrait permettre à l’utilisateur d’effectuer des changements dans le temps s’il le souhaite, rappelle Maddox.
8.Les utilisateurs devraient pouvoir supprimer leurs comptes
À bien des égards, de nombreux systèmes aujourd’hui ne fournissent pas de moyens à l’utilisateur pour fermer son compte de manière permanente et supprimer les données attachées à ce compte. Bien que de nombreuses raisons peuvent être avancées comme l’obligation de conserver les données, lorsqu’il ne s’agit pas de violation d’une loi, les développeurs devraient intégrer l’option de suppression de compte. Dans certains cas, permettre à l’utilisateur de programmer la suppression automatique future de son compte peut s’avérer salutaire comme lorsque le compte d’un utilisateur a été piraté par un tiers malveillant.
9.Limiter la durée de la session ouverte dans certains cas
Pour l’architecte, un des aspects de la sécurité et de l’authentification souvent négligé est la longueur de la session. Bien que l’utilisateur puisse décider de garder sa session ouverte indéfiniment, Maddox souligne qu’il y a des seuils après lesquels le système d’authentification doit demander un mot de passe, un deuxième facteur ou une autre vérification d’utilisateur. Aussi, même s’il n’y a pas de normes précises en la matière, l’architecte recommande comme cela se fait chez Google, de considérer le temps d’inactivité d’un utilisateur pour l’amener à se réauthentifier.
En plus du temps d’inactivité, l’architecte suggère également de vérifier la modification de certains éléments comme la réinitialisation de mots de passe, la modification de son profil et si c’est le cas, de demander une authentification ou un deuxième facteur. En outre, après s’être réauthentifié, l’utilisateur devrait être en mesure de retrouver en l’état les activités de sa dernière session quand elle était ouverte.
10.Utiliser la vérification en deux étapes
Pour éviter des détournements de comptes d’utilisateurs, Maddox recommande d’utiliser le système de double authentification (2 factor authentification abrégé 2FA) le plus sécurisé. Le développeur devrait également utiliser les fournisseurs d’identité tiers et les associer à leur double authentification, ce qui aurait pour conséquence de renforcer la sécurité de son système sans trop d’efforts et de moyens financiers.
11.Rendre les identifiants des utilisateurs insensibles à la casse
Pour faciliter la tâche aux utilisateurs, le système de gestion de comptes d’utilisateurs conçu doit être insensible à la casse. Toutefois, cette opération devrait se faire dans le système et non dans l’interface utilisateur, ce qui limiterait les possibilités des utilisateurs. Si le système de gestion des authentifications est suffisamment robuste, il devrait pouvoir ramener les noms d’utilisateurs ou email entrés par inadvertance en majuscules vers les lettres minuscules.
12.Bâtir un système d’authentification sécurisé
Pour construire un système d’authentification sécurisé, il faut prendre en compte plusieurs aspects comme la réinitialisation du mot de passe, la journalisation des activités du compte, le taux de limitation des tentatives de connexion, le verrouillage des comptes après trop de tentatives infructueuses et l’authentification à deux facteurs pour les appareils non reconnus ou les comptes inactifs depuis longtemps. En raison de toutes ces contraintes, Maddox recommande aux développeurs d’élargir leur champ de connaissance dans ce domaine.
Source : Google Cloud Platform
Et vous ?
Quel est votre avis sur les recommandations faites par l’architecte pour implémenter un bon système d’authentification ;? Vous semblent-elles suffisantes ;? Selon vous, quelles autres recommandations peut-on faire pour implémenter un bon système d’authentification ;?Voir aussi
Google renforce la sécurité de son système d’authentification OAuth pour prévenir la survenue d’attaques de phishing Un chercheur en sécurité explique comment il a contourné le système d’authentification à deux facteurs de PayPal, la faille a été corrigée Authentification à deux facteurs : un système basé sur des photos d’objets ordinaires est à l’étude, l’application de test est disponible sur Android Apple va adopter la méthode d’authentification à deux facteurs sur iOS 11 et macOS High Sierra pour plus de sécurité et de simplicité 
Envoyé par fenkys
, change à chaque fois ...
.