Gestion du cycle de vie des authentifiants et enseignements à tirer sur l’authentification

Voici quelques recommandations de sécurité applicables à la gestion des authentifiants, selon les cas : pour l’utilisateur (en B2C comme en B2B) et/ou pour le fournisseur de ressources a protéger, sachant que la plupart s’appliquent à tous les moyens d’authentification, pas uniquement aux mots/codes de passe. Ces règles sont simples à mettre en place, même si ce n’est malheureusement pas toujours effectif :

• Tous les authentifiants doivent avoir une complexité minimale, en bits d’entropie, ce qui impose notamment une taille minimale, qui dépend de l’espace des caractères utilisées : numériques seuls, alphanumériques seuls, ou plus vaste. En 2023, il est préconisé qu’un authentifiant d’utilisateur tel qu’un mot de passe intègre 80 à 100 bits d’entropie.

• L’inconvénient est que certains utilisateurs (si ce sont eux qui choisissent leur authentifiant) pourraient avoir des difficultés à imaginer un authentifiant qui respectent la complexité nécessaire. Une solution simple est de générer aléatoirement un authentifiant robuste (génération effectuée par l’utilisateur, ou par le fournisseur des ressources accédées), avec un générateur aléatoire de qualité cryptographique, bien entendu. C’est ce que proposent la plupart des coffres-forts numériques (voir plus bas) ;

• Ne pas imposer de limite de taille maximale trop faible, même s’il est prudent d’imposer une limite pour des raisons de sécurité. Par exemple, autoriser au moins 1 Ko de caractères par exemple, notamment pour ne pas exclure les phrases de passe ou des mots de passe long ; ou mieux, fixer la limite maximale en fonction de la taille minimale (50 à 100 fois plus que la taille minimale par exemple) ainsi, la limite maximale changera en fonction des évolutions de la limite minimale ;

• Ne jamais afficher l’authentifiant : ni lors de l’authentification, ni lors d’un changement d’authentifiant, et spécifiquement aux mots/codes de passe : ne jamais afficher le nombre de caractères dont il est composé ;

• Ne jamais transférer un authentifiant « en clair ». Les transferts, y compris lors des renouvellements d’authentifiant, doivent être chiffrés, et le stockage, sous forme de haché cryptographique avec sel ! La seule exception concerne les clefs publiques car ce sont les clefs privées qui sont les authentifiants et qui ne doivent jamais être échangées ou stockées sans protection ;

• Ne jamais divulguer au prouveur d’informations les raisons de ses échecs lors de l’authentification : uniquement l’information que l’authentification est rejetée. Donc aucun message tel que « compte inexistant », « authentifiant erroné », « compte bloqué », ou pire « erreur : mot de passe de 16 caractères attendu », « au moins une lettre minuscule, une majuscule, un chiffre et un caractère non alphanumérique »… c’est ce que l’on constate encore (trop) souvent. Chacun de ces messages dévoilent des informations cruciales aux pirates ;

• L’utilisateur ne doit jamais noter, ou stocker, ses authentifiants sans protection (sur un papier ou dans un fichier, par exemple), mais toujours utiliser un coffre-fort numérique (voir plus bas). S’il est impossible de l’en empêcher, il faut le lui rappeler.

• De même, le fournisseur des ressources accédées ne doit jamais conserver de copies des authentifiants : il n’a besoin que de conserver un haché cryptographique, avec sel. Ce point crucial est encore trop peu respecté, ce qui explique les impacts importants pour les individus, lors des piratages de bases de comptes chez les fournisseurs de services ;

• Les utilisateurs doivent éviter au maximum de réutiliser un même mot de passe pour différentes ressources. La bonne pratique à suivre est « une ressource = un authentifiant distinct », ce qui ne pose pas vraiment de problème, ni de contrainte forte, lorsqu’on utilise un coffre-fort numérique (voir plus bas) ;

• Changer périodiquement ses authentifiants et immédiatement en cas de fuite avérée, par exemple sur le site Have I been Pwned, qui en recense une (petite) partie. Il y a des débats sur la fréquence des changements des authentifiants, qui dépend de plusieurs facteurs dont le type d’authentifiant et son entropie.Recommandation : à titre privé, changer tous ses authentifiants les plus critiques (notamment ceux des ressources sur le web, très exposées) une fois tous les 1 ou 2 ans semble un bon compromis sécurité / utilisabilité et changer une fois tous les 3 à 5 ans pour les authentifiants moins critiques. À noter que ce changement périodique sert deux objectifs : réduire le risque que les comptes associés soient piratés et surtout renforcer ses mots de passe afin qu’ils respectent les préconisations, qui évoluent au cours du temps. Toutefois, le risque de se faire pirater un compte individuel avec un authentifiant robuste est relativement plus faible que celui représenté par les fournisseurs de services lorsqu’ils conservent les authentifiants sans réelles protections et qu’ils sont victimes de piratage de leurs bases de données clients (ce qui est malheureusement relativement fréquent).

• Ne pas laisser ses sessions ouvertes en permanence : les utilisateurs doivent se déconnecter. En effet, fermer leur navigateur web ou une application, ou éteindre leur poste, ne déconnecte généralement pas les sessions ouvertes ! Pour cela, chaque fournisseur de service doit définir une durée maximale, proportionnée à la criticité des ressources, et fermer automatiquement les sessions ouvertes sans activité pendant un laps de temps défini, et tout ceci doit être géré côté serveur bien entendu : tout ce qui est géré côté client peut être corrompu par un pirate ;

• Pour les fournisseurs de ressources, spécifiquement, tracer tous les accès (succès d’authentification) et tentatives d’accès (échecs d’authentification), sans incorporer d’informations sensibles tels que des authentifiants dans ces logs, bien sûr. Le fournisseur se doit de surveiller ces journaux, et les préserver des accès illégitimes ;

• Enfin, suspendre les comptes inactifs, les comptes inutilisés sans aucune connexion depuis un certain laps de temps (durée à définir en fonction de l’usage de la ressource et de la criticité des informations à protéger). Coté fournisseurs de ressources, c’est simple à mettre en place automatiquement, mais pas encore respecté systématiquement. Côté utilisateur, il faut penser à demander la suppression des comptes devenus inutiles, car ne plus les utiliser ne suffit pas à ce qu’ils soient supprimés.

• On ne peut évidemment pas lister exhaustivement ici toutes les bonnes pratiques (comme temporiser entre les tentatives d’authentifications répétées, bloquer temporairement les comptes subissant de nombreux échecs d’authentification, etc.), mais celles-ci donnent déjà un bon aperçu. Je vous invite à vous documenter sur le sujet, les sources sérieuses ne manquent pas, en commençant par les recommandations de l’ANSSI sur l’authentification et les autres publications de l’ANSSI, certaines sont « techniques », d’autres « tout public ».
  • À titre d’information, la CNIL a déjà sanctionné des organismes qui n’appliquaient pas de politique de sécurité stricte des authentifiants (exemple 1, exemple 2 et exemple 3) ou ne vérifiaient pas que leur sous-traitants sécurisaient convenablement l’accès aux données personnelles (exemple).

Pour les ressources particulièrement sensibles ou les comptes qui ne changent pas régulièrement, nous vous conseillons (en 2023) 100 bits d’entropie minimum, et pour les comptes applicatifs, c’est-à-dire les comptes non destinés à des utilisateurs mais à des matériels ou logiciels, la préconisation sera plutôt de 128 bits d’entropie minimum. Dans le cas de clefs cryptographiques : clef SSH de type RSA-4096 ou ED25519-255 minimum.

Un exemple concret : si l’on génère un mot de passe utilisateur (destiné à un humain) de manière aléatoire, avec au moins un caractère numérique, au moins un caractère alphabétique (minuscule et majuscule) et au moins un caractère non alphanumérique (en effet, sur un clavier d’ordinateur de type QWERTY ou AZERTY, il y a environ 95 caractères – dont plus de 30 sont non alphanumériques), la longueur du mot de passe devra être de seize caractères pour atteindre au moins 100 bits d’entropie. Exemple : A]p9H3%gHqG$es=W dispose d’une entropie d’environ 100 bits et a été généré aléatoirement, cela serait donc un mot de passe acceptable.

Voici un tableau comparant l’entropie théorique en fonction de l’espace des caractères utilisés et de la longueur (en orange les combinaisons dépassant les 80 bits, en vert la seule dépassant les 100 bits). « Entropie théorique », car elle ne sera « réelle » que si l’authentifiant est généré aléatoirement, avec un générateur de qualité cryptographique :

Remarque : dans les exemples ci-dessus, vous noterez que nous omettons volontairement les caractères accentués, et plus généralement tous les caractères « spéciaux » (type î, ç, ã, š, ß, æ, etc.). Techniquement, rien n’empêche de les autoriser dans un système d’authentification, toutefois, ils peuvent poser des problèmes aux utilisateurs pour les saisir. En effet, ce sont des sources d’erreurs de frappe, de plus ces caractères ne sont pas directement ou simplement accessibles sur l’ensemble des claviers qu’emploient les utilisateurs : clavier d’ordinateur AZERTY ou QWERTY, smartphone, tablette, etc.

Si le mot de passe n’est pas généré aléatoirement, par exemple, s’il a été choisi par un humain, pour obtenir une robustesse acceptable, il faudra encore augmenter sa longueur, et interdire – et donc vérifier – les mots les plus courants : prénoms, années ou dates, noms d’animaux de compagnie, mots du dictionnaire dans différentes langues, etc., et ce quelle que soit la casse.

Par exemple : aAzZ09+-aAzZ09?! ou Alma+Ambre2023! auront une bonne entropie théorique (environ 100 bits) mais ne sont pas des mots de passe robustes. Leur construction est trop simple, ils contiennent trop de répétitions, des prénoms et une année, bref, des portions aisées à deviner.

Concernant la protection des authentifiants (côté utilisateurs), plus spécialement les mots de passe, même s’ils peuvent servir à d’autres types d’authentifiants, l’usage de coffres-forts numériques est indispensable. Ils peuvent prendre différentes formes, chacune avec ses avantages et ses inconvénients :

• Logiciels ou applications avec base locale : sécurité maximale puisque les authentifiants ne sont pas externalisés, et de plus le fichier du coffre-fort, contenant les authentifiants, peut être aisément répliqué sur un stockage distinct, sous peine de tout perdre en cas d’incident. L’intégration automatique avec les différentes applications qui nécessitent une authentification n’est pas toujours assurée, et l’accès au coffre-fort depuis différents matériels n’est pas toujours trivial.
  • L’exemple le plus connu est KeePass, dont il existe de nombreuses variantes, qui est un logiciel libre et gratuit, qui fait même partie du socle interministériel de logiciels libres préconisés par l’État et dont une version avait même été certifiée par l’ANSSI en 2010. Un autre logiciel, initialement basé sur KeePass et multiplateforme, est KeePassXC (notez que ce n’est pas le logiciel qui a été préconisé et certifié).
  • KeePass propose également des générateurs de mots de passe aléatoires, que l’on peut paramétrer, et un indicateur de qualité (= entropie) des mots de passe stockés.

• Intégrés dans les navigateurs web : la sécurité dépend avant tout du navigateur web et de la manière dont il sécurise l’accès aux authentifiants. Certains navigateurs web stockent les authentifiants en local, sous forme chiffrée, avec une clef de protection, connue seulement de l’utilisateur. D’autres navigateurs web stockent vos authentifiants sur le web (dans un cloud), et sans clef de protection connue de l’utilisateur, ce qui n’est pas sans risques. Ceci dit, utiliser le coffre-fort de son navigateur web est la solution la plus pratique pour gérer l’accès à des ressources en ligne, toutefois, elle n’est pas utilisable pour des ressources hors web, comme les authentifiants système ou d’applications/logiciels non web.
  À noter qu’il existe également des extensions à certains navigateurs web pour s’interfacer avec certains coffres-forts installés, tel qu’avec KeePass, mais il convient de rester vigilant avec les extensions : on ne sait pas toujours si elles sont totalement exemptes de risques !

• Coffre-fort en ligne : le point fort de ces solutions est la simplicité d’utilisation et l’accès au coffre-fort depuis divers matériels de manière aisée. Toutefois, ceci est parfois réalisé au détriment de la sécurité qui est très variable d’un éditeur à un autre (de graves fuites ont déjà eu lieu chez des éditeurs de tels produits, comme celle de LastPass en 2022), et les vraies « garanties » dans ce domaine dépendent de chaque solution.

Quelle(s) que soi(en)t la, ou les, solutions choisies, assurez-vous toujours qu’il y a un authentifiant principal robuste, connu de vous seul, qui protège l’accès à vos coffres-forts et que la sécurité du coffre-fort a été éprouvée par un tiers de confiance ou une certification de sécurité, par exemple. Dans le cas contraire, ou en cas de doute, préférez un autre coffre-fort.

Dans le cas particulier de l’authentification applicative, c’est-à-dire lorsqu’une application cliente ou un matériel doit s’authentifier auprès d’une ressource, elle-même informatique, il n’y a aucune solution parfaitement sûre à ce jour pour protéger l’authentifiant applicatif côté matériel ou application cliente, puisqu’il n’y a aucune action humaine possible. Un exemple concret est une application web qui doit s’authentifier, sans l’aide d’un humain, auprès d’une base de données.

• L’authentifiant doit forcément être stocké « en clair » – tout en évitant de l’intégrer au code source de l’application – et accessible à l’application cliente (le prouveur). Certains chiffrent cet authentifiant, en utilisant par exemple un coffre-fort numérique, mais dans ce cas c’est la clef de déchiffrement qui doit être stockée en clair, et accessible à l’application cliente : cela ne fait que décaler le problème, et bien que cela semble le complexifier un petit peu, au final, il y aura toujours un secret en clair quelque part.

• D’autres variantes plus professionnelles tentent de complexifier l’accès au mot de passe en l’enfouissant dans une puce ou dans les tréfonds du système d’exploitation, ce ne sont que des palliatifs, même s’ils ne sont pas totalement inutiles pour autant : ils retardent effectivement l’accès illicite mais, au final, l’application cliente doit pouvoir récupérer automatiquement son authentifiant, sans intervention humaine.

Enfin, pour clore ce chapitre, un dernier conseil très important : avant de vendre, de donner ou de mettre au rebut vos appareils (ordinateurs, smartphones, etc.) personnels comme professionnels, si votre matériel fonctionne, n’oubliez jamais de :

• Récupérer vos authentifiants. Si vous utilisez un coffre-fort numérique ce sera simple, il n’y aura qu’un seul fichier à copier !

• Supprimer vos authentifiants enregistrés dans tous les logiciels et applications que vous utilisiez. Ceci est spécifique à chaque logiciel ou application. Exemples, avec un ordinateur :
  • Une technique à la portée de tous (mais pas toujours efficace à 100%) est de désinstaller complètement les logiciels en question, et accepter de supprimer toutes les données, s’ils le proposent. Ensuite, d’utiliser un logiciel d’effacement sécurisé (sur Windows il y a par exemple Eraser) qui effacera définitivement l’espace libre contenant potentiellement des données mal effacées par les logiciels.
  • L’autre solution, certes moins triviale, mais plus efficace, est d’effacer complètement le support de stockage, c’est-à-dire le disque ou la carte mémoire, et donc le système d’exploitation et tous les logiciels. À nouveau, avec un logiciel d’effacement sécurisé (car un simple formatage ne suffit pas), mais depuis un support amorçable, un support externe « bootable », souvent désigné « Live USB ». Puis de réinstaller le système d’exploitation à la fin, si nécessaire, comme en cas de vente ou de don de l’appareil.

• Et si l’appareil ne fonctionne plus (s’il est en panne), il ne faudra pas oublier de retirer les disques de stockage, tenter de les effacer en les connectant à un autre appareil, ou à défaut, les détruire physiquement. Il existe de multiples techniques de destruction physique : perçage, bain d’acide, démagnétisation, broyage ou autres. Bien sûr, selon le type de disque – HDD ou SSD – et la technique choisie, certaines ne seront pas efficaces. Cependant, ces techniques ne sont pas à la portée de tous car elles nécessitent du matériel, des protections (attention aux bains d’acide !) et un certain savoir-faire pour être réellement efficaces. Par conséquent, il est plus sage de faire appel à des services de destruction de disques durs, qui sont payants, donc plutôt destinés aux disques dans le cadre professionnel.

Force est de constater qu’il n’y a pas encore d’alternative définitive, systématiquement meilleure et qui élimine totalement les mots passe si l’on tient compte de tous les aspects, en particulier la sécurité réelle et les alternatives existantes (coffre-forts numériques par exemple), et tous les types d’usages. Par exemple, la plupart des mécanismes bi-facteurs utilisent au moins un mot, ou un code, de passe. Au final, il semble peu probable que l’on puisse se passer totalement des mots de passe dans un avenir proche : ils auront encore longtemps la vie dure !

Par contre, en tenant compte des contraintes et risques, d’autres systèmes d’authentification correctement conçus et utilisés sont des alternatives crédibles, et même souhaitables : par exemple, les clefs de passe cryptographiques , certaines authentifications bi-facteurs de nature différente et n’utilisant que des canaux sécurisés (donc pas par SMS).

Selon l’environnement (utilisateurs dans le cadre privé, collaborateurs dans le cadre professionnel), les contraintes ne sont d’ailleurs pas les mêmes : appareils (ordinateurs, smartphones, etc.) très hétéroclites dans le premier cas, appareils plus homogènes dans le second.

Mais le problème est parfois abordé par le mauvais point de vue :

• Premièrement, il faudrait étudier et tenir compte de la criticité des données à protéger avant de choisir le mécanisme d’authentification, ce qui ne semble pas toujours le cas : un site d’albums photos n’engendre par les mêmes risques qu’un site de santé ou de services bancaires ;

• Ensuite, ne jamais permettre aux utilisateurs de choisir un authentifiant non robuste, mais plutôt leur générer un mot de passe robuste ;

• De même, et c’est au moins aussi important que les recommandations précédentes : étudier et proposer des solutions pour simplifier l’expérience utilisateur (coffre-fort numérique, par exemple), informer et sensibiliser ses utilisateurs aux risques, aux bonnes pratiques, etc. ;

• Enfin, et là je m’adresse à tous les utilisateurs : protégez vos authentifiants, et ne les prêtez jamais : « Un authentifiant, c’est comme une brosse à dents : cela ne se prête pas, et cela se change régulièrement ».

Cela dit, et là je m’adresse aux architectes, concepteurs, et développeurs informatiques, ainsi qu’aux administrateurs systèmes, il ne faut évidemment pas rejeter d’emblée, ou définitivement, les « nouveaux » systèmes d’authentification. Quelle que soit la technologie d’authentification, il faut l’étudier en détail, en gardant un regard critique et constructif, avant d’envisager de la mettre en place : ses atouts sans négliger d’étudier ses faiblesses et s’assurer qu’elle respecte les principes de security & privacy by default & by design. Cela ne doit pas se faire à la légère et cette phase est également indispensable lors du déploiement : même un système théoriquement très sûr, ne le sera pas du tout, s’il est mal maitrisé ou mal utilisé. Ce conseil s’applique à tous les systèmes d’authentification, y compris les plus simples en apparence (les mots de passe).

Depuis au moins une dizaine d’années, on voit fleurir quantités d’articles racoleurs dans la presse dite « spécialisée » qui annoncent péremptoirement que « Telle ou telle nouvelle technologie va mettre au rancart, ou remplacer, tous les mots de passe ! ». Généralement, lorsqu’on voit ce type d’affirmation, il s’agit au mieux d’articles naïfs (car dans la plupart des systèmes, même bi-facteurs, il y a toujours au moins un mot/code de passe), voire d’articles « commandés » (promotionnels ou sponsorisés), c’est-à-dire des publicités « déguisées » en article de presse.

Vous l’avez compris, les mots de passe font preuve de résilience, et risquent de perdurer dans notre quotidien encore un certains temps… jusqu’à ce qu’un groupe de chercheurs géniaux invente un concept original et réellement novateur (au sens d’une rupture technologique dans le mode actuel de pensée), comme cela a été le cas au milieu des années 70, avec l’invention de l’échange publique de clefs (échange de clés Diffie-Hellman) que personne ne croyait possible, jusqu’à l’idée de génie… de ces deux génies ; ou dans un autre domaine de la SSI, avec la preuve de concept de chiffrement homomorphique de Craig Gentry en 2009. Ce dernier n’a certes aucun rapport avec l’authentification, mais il permet d’envisager un jour de pouvoir manipuler des données chiffrées sans avoir besoin de les déchiffrer, ce qui ouvre des perspectives intéressantes, notamment avec la sous-traitance en général, et avec les cloud en particulier. Mais ceci est une tout autre histoire… ;o)