Au sommaire :
Références
NOR : CNIL2229344X
Source : JORF n°0241 du 16 octobre 2022, texte n° 121
En-tĂȘte
La Commission nationale de l’informatique et des libertĂ©s,
Vu le rĂšglement (UE) 2016/679 du Parlement europĂ©en et du Conseil du 27 avril 2016 relatif Ă la protection des personnes physiques Ă l’Ă©gard du traitement des donnĂ©es Ă caractĂšre personnel et Ă la libre circulation de ces donnĂ©es, et abrogeant la directive 95/46/CE (rĂšglement gĂ©nĂ©ral sur la protection des donnĂ©es) ;
Vu la loi n° 78-17 du 6°janvier 1978 modifiĂ©e relative Ă l’informatique, aux fichiers et aux libertĂ©s, notamment ses articles notamment son article 8-I-2°-b ;
Article
AprÚs avoir entendu le rapport M. François PELLEGRINI, commissaire, et les observations de M. Benjamin TOUZANNE, commissaire du Gouvernement,
Article 1
Adopte la présente recommandation :
L’article 32 du rĂšglement gĂ©nĂ©ral sur la protection des donnĂ©es (RGPD) impose que tout traitement de donnĂ©es Ă caractĂšre personnel soit protĂ©gĂ© par des mesures techniques et organisationnelles appropriĂ©es aux risques spĂ©cifiques que le traitement fait peser sur la protection des donnĂ©es Ă caractĂšre personnel.
A cette fin, de nombreux traitements utilisent des mots de passe ou autres secrets non partagĂ©s afin de protĂ©ger l’accĂšs aux donnĂ©es qu’ils contiennent.
La multiplication des attaques informatiques, qui a entraĂźnĂ© la compromission de bases de donnĂ©es contenant notamment les mots de passe associĂ©s aux comptes des personnes concernĂ©es, a pour consĂ©quence l’amĂ©lioration des connaissances des attaquants en matiĂšre de mots de passe.
Par ailleurs, l’emploi par les utilisateurs d’un mĂȘme mot de passe pour diffĂ©rents comptes en ligne, et/ou de mots de passe fondĂ©s sur des informations publiques les concernant (date de naissance, prĂ©noms des enfants, etc.) renforce l’obligation pour les responsables de traitement de mettre en Ćuvre les mesures permettant d’assurer la sĂ©curitĂ© des donnĂ©es Ă caractĂšre personnel qu’ils gĂšrent.
La Commission estime nĂ©cessaire, dans l’objectif d’apporter une plus grande confiance dans les services numĂ©riques, de dĂ©finir des modalitĂ©s techniques de cette mĂ©thode d’authentification Ă mĂȘme de garantir un niveau de sĂ©curitĂ© adaptĂ©. Pour ce faire, la CNIL a dĂ©cidĂ© d’adopter une recommandation ayant pour objectif de dĂ©finir les exigences techniques et organisationnelles minimales pour les authentifications par mot de passe ou par tout autre secret non partagĂ© (Ă l’exception des clĂ©s et secrets cryptographiques) mis en Ćuvre dans le cadre de traitements de donnĂ©es Ă caractĂšre personnel. Celle-ci constitue une mise Ă jour de son rĂ©fĂ©rentiel technique destinĂ© Ă apporter un niveau de sĂ©curitĂ© minimal, en cohĂ©rence avec les bonnes pratiques de sĂ©curitĂ© et concrĂštement applicable Les dispositions de cette recommandation, qui n’ont pas un caractĂšre normatif, correspondent Ă l’Ă©tat de l’art auquel tout responsable de traitement devrait se conformer, a minima, pour satisfaire aux obligations de l’article 32 du RGPD lorsqu’il utilise une authentification par mots de passe pour protĂ©ger un traitement.
Les acteurs peuvent mettre en Ćuvre d’autres mesures de sĂ©curitĂ© que celles dĂ©crites dans cette recommandation s’ils sont en capacitĂ© de montrer qu’elles garantissent un niveau de sĂ©curitĂ© au moins Ă©quivalent. La Commission a notamment toujours considĂ©rĂ© que d’autres moyens d’authentification, comme par exemple l’authentification Ă double facteur ou les certificats Ă©lectroniques, offrent davantage de sĂ©curitĂ© que le seul mot de passe. Pour aller plus loin et, notamment, dĂ©terminer les mesures nĂ©cessaires Ă mettre en Ćuvre dans le cas oĂč le niveau minimal dĂ©crit est insuffisant, cette recommandation sera utilement complĂ©tĂ©e par le guide de l’Agence nationale de la sĂ©curitĂ© des systĂšmes d’information (ANSSI) intitulĂ© « Recommandations relatives Ă l’authentification multifacteur et aux mots de passe ».
Pour l’Ă©laboration de cette recommandation, la Commission a Ă©changĂ© avec ses homologues europĂ©ens, l’ANSSI et les experts du domaine au moyen d’une consultation publique qui s’est tenue du 21 octobre 2021 au 10 dĂ©cembre 2021.
1. Recommandations générales en matiÚre de sécurité des mots de passe
Le terme « mot de passe » dĂ©signe, dans cette dĂ©libĂ©ration, tout facteur de connaissance (1), c’est-Ă -dire tout ensemble d’informations rĂ©vocable, connu uniquement de la personne concernĂ©e et permettant ou contribuant Ă l’authentification de celle-ci ; il inclut, notamment, les « phrases de passe » (rĂ©putĂ©es plus longues que les mots de passe) et les codes de dĂ©verrouillage, et exclut les clĂ©s et secrets cryptographiques.
Tout responsable de traitement utilisant des mots de passe doit garantir un niveau minimal de sĂ©curitĂ© reposant, d’une part, sur une longueur et une complexitĂ© suffisantes, Ă©quivalentes Ă une entropie de 80 bits sans mesure complĂ©mentaire et, d’autre part, sur des rĂšgles de mise en Ćuvre et de gouvernance permettant de prĂ©server la sĂ©curitĂ© du mot de passe tout au long de son cycle de vie.
La notion de « devinabilitĂ© » est une approche alternative pour dĂ©terminer la robustesse d’un mot de passe. Elle consiste Ă Ă©valuer, au moyen de traitements algorithmiques dĂ©diĂ©s, la facilitĂ© pour un adversaire de retrouver un mot de passe donnĂ©. Il s’agit donc, non pas de vĂ©rifier le respect d’une politique de mots de passe fixant une complexitĂ© formelle minimale, mais d’Ă©valuer dynamiquement la rĂ©sistance du mot de passe choisi. La littĂ©rature sur le sujet recommande une rĂ©sistance aux attaques minimale de 1014 essais. Cependant, au moment de la publication de cette recommandation, les outils pour mettre en Ćuvre cette mĂ©thode, a priori plus fiable que la seule vĂ©rification de complexitĂ©, ne sont pas encore disponibles pour des utilisateurs francophones ; la Commission ne dispose donc pas actuellement du recul nĂ©cessaire pour dĂ©terminer le niveau de rĂ©sistance Ă©quivalent aux niveaux dĂ©crits dans la prĂ©sente recommandation. Elle sera attentive aux nouveaux dĂ©veloppements dans ce domaine, notamment quant Ă la disponibilitĂ© de solutions librement accessibles qu’elle pourra Ă©valuer.
Les risques spĂ©cifiques Ă certains traitements (par exemple, les traitements de donnĂ©es sensibles au sens de l’article 9 du RGPD, tels que les traitements de donnĂ©es de santĂ©, ou des traitements Ă large Ă©chelle, ou encore dans le cas de traitements particuliers comme la fourniture d’un service de messagerie Ă©lectronique ou d’un gestionnaire de mots de passe) ou Ă certaines catĂ©gories d’utilisateurs (par exemple, les administrateurs informatiques) nĂ©cessiteront des mesures plus contraignantes que celles dĂ©finies dans cette recommandation, comme par exemple la mise en Ćuvre d’un processus d’authentification multi-facteurs. Dans certains cas, des rĂ©glementations spĂ©cifiques peuvent imposer un niveau minimum d’authentification plus exigeant que celui dĂ©fini dans la prĂ©sente recommandation.
De plus, les opĂ©rations relatives Ă la gestion des mots de passe confiĂ©es, pour tout ou partie, Ă un sous-traitant, doivent respecter les conditions posĂ©es Ă l’article 28 du RGPD. Dans ces cas de figure, les rĂŽles et responsabilitĂ©s doivent ĂȘtre prĂ©cisĂ©ment dĂ©finis et formalisĂ©s, le niveau de sĂ©curitĂ© requis et les objectifs de sĂ©curitĂ© assignĂ©s au sous-traitant clairement dĂ©finis, compte tenu de la nature du traitement et des risques qu’il est susceptible d’engendrer.
Enfin, si les simples éditeurs de logiciels ne sont pas soumis au cadre juridique relatif à la protection des données, la documentation relative aux logiciels qui traitent des mots de passe devrait préciser de façon détaillée les modalités de génération, stockage et transmission des mots de passe afin de faciliter la mise en conformité des utilisateurs de ces logiciels.
(1) Pour rappel, les mots de passe constituent l’un des trois facteurs possibles d’authentification dĂ©finis par le guide en matiĂšre d’authentification de l’ANSSI et de la CNIL, qui sont : les facteurs de « connaissance » (dĂ©tention d’une information secrĂšte), de « possession » (dĂ©tention d’un objet unique, tel qu’une carte Ă puce) et l’« inhĂ©rence » (caractĂ©ristique biomĂ©trique propre).
2. Sur la gouvernance
Tout organisme utilisant une authentification reposant sur des mots de passe définit une politique de gestion de ceux-ci.
Cette politique est rĂ©digĂ©e par les acteurs en charge de la sĂ©curitĂ© et des moyens informatiques dans l’organisme (RSSI, DSI, DPD/DPO, par exemple) et validĂ©e par le responsable de traitement.
Le responsable de traitement doit s’assurer du respect de cette politique par des solutions techniques et organisationnelles. A cette fin, il met en Ćuvre une revue rĂ©guliĂšre, par exemple annuelle, des habilitations et de l’application de cette politique afin de vĂ©rifier sa bonne mise en Ćuvre et dĂ©tecter si une mise Ă jour est nĂ©cessaire.
Les personnes concernĂ©es doivent ĂȘtre informĂ©es des rĂšgles de cette politique qui leur sont applicables. Elles doivent Ă©galement ĂȘtre sensibilisĂ©es aux menaces et aux risques de compromission de leurs mots de passe, ainsi qu’au comportement Ă adopter en cas de suspicion de compromission de ceux-ci. Les formations ou informations doivent ĂȘtre adaptĂ©es aux diffĂ©rents publics, Ă leurs compĂ©tences, Ă leur niveau de responsabilitĂ© et Ă la sensibilitĂ© des donnĂ©es auxquelles ils ont accĂšs. Ces formations pourront utilement inclure un encouragement Ă l’utilisation de gestionnaires de mots de passe, ainsi qu’une information sur les bonnes pratiques relatives Ă leur utilisation (notamment sur la nĂ©cessitĂ© d’un mot de passe maĂźtre fort, d’une complexitĂ© dĂ©passant les minima dĂ©finis par cette recommandation et la nĂ©cessitĂ© de sauvegarder rĂ©guliĂšrement la base des mots de passe). Des outils ou indicateurs peuvent ĂȘtre mis Ă disposition des utilisateurs pour leur permettre d’Ă©valuer, au moment de la crĂ©ation d’un nouveau mot de passe, la robustesse de ce dernier. Dans ce cas, une vigilance particuliĂšre devra ĂȘtre portĂ©e Ă la provenance, la sĂ©curitĂ© et la pertinence des outils ou indicateurs choisis.
3. Sur les modalitĂ©s opĂ©rationnelles de l’utilisation de mots de passe
3.1. Préambule et définitions
Les rĂšgles et recommandations dĂ©crites dans les annexes B1 et B2 du rĂ©fĂ©rentiel gĂ©nĂ©ral de sĂ©curitĂ© (2) (RGS) ainsi que dans le guide des mĂ©canismes cryptographiques de l’ANSSI (3) font rĂ©fĂ©rence pour ce qui doit ĂȘtre considĂ©rĂ© comme un « algorithme public rĂ©putĂ© fort ». Pour assurer que « la mise en Ćuvre logicielle est exempte de vulnĂ©rabilitĂ© connue », la Commission recommande de ne choisir que des logiciels ou composants logiciels faisant l’objet d’une maintenance de sĂ©curitĂ© rĂ©guliĂšre, de n’utiliser que les versions Ă jour de ceux-ci et d’effectuer une veille sur leur sĂ©curitĂ©.
On appelle « entropie » la quantitĂ© de hasard contenue dans un systĂšme. Pour un mot de passe ou une clĂ© cryptographique, cela correspond Ă son degrĂ© d’imprĂ©dictibilitĂ©, et donc Ă sa capacitĂ© de rĂ©sistance Ă une attaque par force brute. Dans le cadre de cette recommandation, le terme d’entropie, appliquĂ© Ă un mot de passe, correspond Ă son entropie idĂ©ale dans l’hypothĂšse oĂč il serait gĂ©nĂ©rĂ© alĂ©atoirement. En informatique, on mesure couramment l’entropie en nombre de « bits », c’est-Ă -dire en nombre de chiffres binaires (valant soit « 0 », soit « 1 ») permettant d’exprimer la mĂȘme quantitĂ© de hasard. Ainsi, un code de carte bancaire Ă quatre chiffres dĂ©cimaux pris au hasard, valant chacun de « 0 » à « 9 », donne dix mille combinaisons possibles (10 Ă la puissance 4, notĂ© 104). Pour obtenir un nombre de combinaisons binaires Ă©quivalent, il faut utiliser 13 bits, car 2 Ă la puissance 13 (ou 213) vaut 8 192, qui est du mĂȘme ordre de grandeur que 104. On dira donc qu’un code de quatre chiffres dĂ©cimaux alĂ©atoires possĂšde une entropie de 13 bits. Ces calculs peuvent s’appliquer Ă tout ensemble de caractĂšres : 26 choix possibles par caractĂšre pour des lettres majuscules, 52 pour des lettres majuscules et minuscules, 62 si l’on y ajoute les chiffres, etc.
Toute rĂšgle de construction d’un mot de passe conduit Ă limiter l’espace des choix possibles, et donc Ă limiter son entropie pour une longueur donnĂ©e. Par exemple, choisir un mot de passe parmi les mots d’une langue revient Ă limiter trĂšs fortement le nombre de combinaisons de lettres possibles en pratique. En effet, chaque langue n’admet qu’un nombre limitĂ© de suites de lettres, servant Ă former les syllabes des mots. La tentation, pour de nombreux utilisateurs, de choisir des mots de passe « simples Ă retenir » facilite les attaques dites « par dictionnaire » dans lesquelles, au lieu de tester par force brute l’intĂ©gralitĂ© des combinaisons possibles, n’en sont testĂ©es qu’un nombre trĂšs limitĂ©, comprenant des mots du dictionnaire, des prĂ©noms ou des dates, ainsi que leurs dĂ©rivations « classiques » (par exemple, du mot « kangourou », seront dĂ©rivĂ©es et testĂ©es des combinaisons telles que « k4ng0urou », « kangourou01 », « KaNgOuRoU », « Kangourou_1969 », etc.).
De fait, lorsque les utilisateurs ont la libertĂ© de choisir comme mot de passe des combinaisons qui ne sont pas strictement alĂ©atoires, il est nĂ©cessaire, pour conserver un niveau d’entropie donnĂ©, de choisir une politique de mots de passe privilĂ©giant la longueur des mots de passe par rapport Ă leur complexitĂ©, voire, en fonction des risques, d’augmenter le nombre de bits d’entropie cible pour la politique de mots de passe. En effet, pour les utilisateurs employant gĂ©nĂ©ralement des mots du dictionnaire, il est prĂ©fĂ©rable d’imposer des mots de passe les amenant Ă choisir une sĂ©rie de mots plutĂŽt qu’un seul. Il est recommandĂ© de les guider dans ce choix, en leur rappelant notamment qu’il est prĂ©fĂ©rable de choisir des mots qui n’ont pas de liens entre eux.
A ce propos, le dĂ©compte des caractĂšres qui seront utilisĂ©s pour la crĂ©ation d’un mot de passe devra ĂȘtre rĂ©aliste. Ainsi, il conviendra de ne prendre en compte que les caractĂšres habituellement intĂ©grĂ©s par les utilisateurs dans leurs mots de passe et, notamment, uniquement les caractĂšres spĂ©ciaux disponibles sur les claviers habituellement accessibles et utilisĂ©s par les utilisateurs concernĂ©s. Dans le cas d’un usage dans diffĂ©rents environnements (ordinateur, ordiphone), les jeux de caractĂšres considĂ©rĂ©s doivent ĂȘtre accessibles dans l’ensemble des environnements des utilisateurs.
Enfin, il convient Ă©galement de recommander aux utilisateurs de ne pas utiliser, pour construire leurs mots de passe, d’informations personnelles (date de naissance, prĂ©noms des proches, etc.), ces inclusions Ă©tant Ă mĂȘme de faciliter des attaques ciblĂ©es les concernant.
(2) https://www.ssi.gouv.fr/administration/reglementation/confiance-numerique/le-referentiel-general-de-securite-rgs/liste-des-documents-constitutifs-du-rgs-v-2-0/.
(3) https://www.ssi.gouv.fr/entreprise/guide/mecanismes-cryptographiques/.
3.2. ModalitĂ©s de l’authentification par mot de passe
Lorsque l’authentification par mot de passe s’effectue au moyen d’une connexion rĂ©seau, et a fortiori si cette derniĂšre est opĂ©rĂ©e par un tiers, la Commission recommande :
– qu’une mesure de contrĂŽle de l’identitĂ© du serveur d’authentification par le client soit mise en Ćuvre, au moyen d’un certificat d’authentification de serveur ;
– que le canal de communication entre le serveur authentifiĂ© et le client soit chiffrĂ© Ă l’aide d’une fonction de chiffrement sĂ»re (c’est-Ă -dire mettant en Ćuvre un algorithme public rĂ©putĂ© fort dont la mise en Ćuvre logicielle est exempte de vulnĂ©rabilitĂ© connue) ;
– que des mesures de sĂ©curitĂ© renforcĂ©es soient mises en Ćuvre afin de garantir la confidentialitĂ© des clĂ©s privĂ©es utilisĂ©es ;
– que les mots de passe n’apparaissent pas dans les adresses des ressources distantes, ni en clair, ni sous forme hachĂ©e.
Les deux premiers points peuvent notamment ĂȘtre mis en Ćuvre par l’utilisation du protocole TLS dans une configuration respectueuse des recommandations de l’ANSSI en la matiĂšre, exposĂ©es dans son document SDE-NT-35/ANSSI/SDE/NP1 intitulĂ© « Recommandations de sĂ©curitĂ© relatives Ă TLS ».
Lorsque l’authentification par mot de passe s’effectue sur une page web, il est recommandĂ© que cette page ne contienne pas de code rĂ©alisant des appels externes (publicitĂ©s, briques logicielles et contenus tiers, etc.), afin de limiter les vecteurs d’attaques pouvant mener Ă la compromission des mots de passe.
Dans les champs de saisie des mots de passe, les caractĂšres saisis ne doivent pas ĂȘtre visibles par dĂ©faut ; ils doivent rester invisibles ou ĂȘtre reprĂ©sentĂ©s par un caractĂšre neutre tel qu’un point ou une Ă©toile.
En cas d’Ă©chec de l’authentification, le message d’information affichĂ© devrait indiquer l’Ă©chec sans fournir d’information susceptible d’aider un attaquant potentiel.
Tout dispositif mettant en Ćuvre des mots de passe par dĂ©faut (qu’ils soient gĂ©nĂ©rĂ©s automatiquement ou par une personne initialisant le compte pour l’utilisateur) ne doit fournir que des mots de passe Ă usage temporaire et/ou doit imposer leur modification Ă la premiĂšre connexion. IdĂ©alement, le systĂšme devrait contraindre l’utilisateur Ă effectuer cette modification avant de lui permettre de rĂ©aliser d’autres actions.
S’agissant des modalitĂ©s de crĂ©ation d’un mot de passe requis pour l’authentification Ă un compte, le responsable de traitement doit s’assurer que les mots de passe utilisĂ©s sont d’un niveau de sĂ©curitĂ© suffisant, par exemple en imposant une taille et une complexitĂ© minimales. La personne ayant recours Ă une authentification par mot de passe doit ĂȘtre prĂ©alablement informĂ©e de l’ensemble des Ă©lĂ©ments de la politique mise en Ćuvre par le responsable de traitement qu’elle doit respecter et, notamment, le cas Ă©chĂ©ant, les tailles minimale et maximale des mots de passe si celles-ci sont susceptibles de ne pas ĂȘtre naturellement respectĂ©es par l’utilisateur.
En dehors du cas des codes de dĂ©verrouillage (voir cas n° 4), dĂšs lors que le responsable de traitement identifie un risque liĂ© Ă la soumission abusive de mots de passe (notamment, si le traitement est accessible depuis internet), il convient de fixer une taille maximale pour les champs des mots de passe. Celle-ci doit ĂȘtre suffisamment grande pour permettre l’utilisation de phrases comme mots de passe, tout en Ă©vitant les attaques par dĂ©ni de service rĂ©sultant du traitement d’un mot de passe abusivement long. Leur taille maximale ne saurait en principe ĂȘtre infĂ©rieure Ă 50 caractĂšres pour une authentification par mot de passe avec ou sans restriction de compte (cas n° 1 et 2). Elle pourra ĂȘtre, par exemple, de l’ordre de quelques centaines de caractĂšres.
Afin d’encourager l’utilisation des gestionnaires de mots de passe et d’amĂ©liorer l’accessibilitĂ© numĂ©rique, des mĂ©canismes ayant pour objet ou effet d’interdire aux utilisateurs de coller un mot de passe dans les champs de saisie ne doivent pas ĂȘtre mis en Ćuvre, tant lors de la crĂ©ation du mot de passe que de sa modification ou de son utilisation lors de l’Ă©tape d’authentification.
A l’exception des envois par voie postale, les mots de passe ne doivent pas ĂȘtre communiquĂ©s Ă l’utilisateur en clair, notamment par courrier Ă©lectronique. Seuls des mots de passe temporaires ou Ă usage unique devraient ĂȘtre communiquĂ©s aux utilisateurs.
Dans le cas d’un envoi par voie postale, l’usage de mesures complĂ©mentaires destinĂ©es Ă dĂ©tecter son interception (par exemple : enveloppes dont l’intĂ©rieur est noirci pour Ă©viter la lecture par transparence, cases Ă gratter) ou Ă en empĂȘcher l’usage (par exemple : renouvellement forcĂ© lors de la premiĂšre utilisation du mot de passe envoyĂ©) devraient ĂȘtre mis en Ćuvre.
Dans le cas de l’envoi de liens de crĂ©ation ou de renouvellement de mot de passe, une durĂ©e d’expiration courte est dĂ©finie, dans la plupart des cas de quelques heures et d’au plus de 24 heures. Cependant, dans le cas d’un envoi par courrier, la durĂ©e de validitĂ© pourrait ĂȘtre plus longue.
Lorsqu’un mot de passe est refusĂ© lors de sa crĂ©ation, un message d’information clair rappelant la politique de l’organisation en termes de mot de passe et explicitant la raison du refus doit ĂȘtre affichĂ© Ă l’utilisateur. Dans la mesure du possible, le responsable de traitement doit conseiller et guider l’utilisateur dans la crĂ©ation de son mot de passe.
Les mots de passe connus comme Ă©tant couramment utilisĂ©s ne devraient pas ĂȘtre acceptĂ©s. La taille et le contenu de la liste de mots de passe Ă refuser doivent ĂȘtre proportionnels aux risques et, le cas Ă©chĂ©ant, adaptĂ©s au contexte d’usage (par exemple, en incluant des listes de mots de passe interdits spĂ©cifiques au service utilisĂ©). Dans tous les cas, l’utilisateur doit ĂȘtre informĂ© que les mots de passe les plus courants ne sont pas acceptĂ©s.
En cohĂ©rence avec les recommandations de l’ANSSI en matiĂšre d’authentification dĂ©crites dans le guide intitulĂ© « Recommandations relatives Ă l’authentification multifacteur et aux mots de passe », la Commission dĂ©crit trois possibilitĂ©s d’exigences minimales pour une authentification par mot de passe. Le cas d’usage et le public ciblĂ© doivent ĂȘtre pris en compte dans le choix des critĂšres Ă imposer dans la politique de gestion des mots de passe.
Le premier cas fait reposer la sĂ©curitĂ© principalement sur le mot de passe ; il impose par consĂ©quent des exigences importantes en termes de niveau d’entropie, et donc de taille et de complexitĂ© du mot de passe. Dans les cas suivants, l’existence de mesures complĂ©mentaires visant Ă assurer un niveau de sĂ©curitĂ© similaire permet le recours Ă des mots de passe d’entropie plus faible.
Dans tous les cas, comme indiquĂ© en introduction, les niveaux d’entropie dĂ©crits ci-dessous sont des limites basses. En fonction des risques, un niveau minimal plus Ă©levĂ© peut ĂȘtre nĂ©cessaire.
– Cas n° 1 : mot de passe seul
La robustesse de cette authentification reposant exclusivement sur la qualitĂ© intrinsĂšque du mot de passe de l’utilisateur, la complexitĂ© Ă fixer dans la politique de mots de passe doit permettre d’assurer l’Ă©quivalent d’une entropie d’au moins 80 bits. Les trois exemples ci-dessous correspondent Ă cette entropie.
Exemple 1 : les mots de passe doivent ĂȘtre composĂ©s d’au minimum 12 caractĂšres comprenant des majuscules, des minuscules, des chiffres et des caractĂšres spĂ©ciaux Ă choisir dans une liste d’au moins 37 caractĂšres spĂ©ciaux possibles.
Exemple 2 : les mots de passe doivent ĂȘtre composĂ©s d’au minimum 14 caractĂšres comprenant des majuscules, des minuscules et des chiffres, sans caractĂšre spĂ©cial obligatoire.
Exemple 3 : les phrases de passe fondĂ©es sur des mots de la langue française doivent ĂȘtre composĂ©es d’au minimum 7 mots.
– Cas n° 2 : mot de passe et restriction d’accĂšs au compte
Quand l’authentification prĂ©voit un mĂ©canisme de restriction de l’accĂšs au compte (voir exemples ci-dessous), la complexitĂ© Ă fixer dans la politique de mots de passe doit permettre d’assurer l’Ă©quivalent d’une entropie d’au moins 50 bits.
Exemple 1 : la taille du mot de passe doit ĂȘtre au minimum de 8 caractĂšres et comporter 3 des 4 catĂ©gories de caractĂšres (majuscules, minuscules, chiffres et caractĂšres spĂ©ciaux), les caractĂšres spĂ©ciaux devant ĂȘtre pris dans un ensemble d’au moins 11 caractĂšres.
Exemple 2 : les phrases de passe fondĂ©es sur des mots de la langue française doivent ĂȘtre composĂ©es d’au minimum 5 mots.
Exemple 3 : les mots de passe doivent ĂȘtre composĂ©s d’au minimum 16 chiffres.
L’authentification doit alors faire intervenir un mĂ©canisme de restriction d’accĂšs au compte. Celui-ci peut prendre une ou plusieurs des formes suivantes :
– une temporisation de l’accĂšs au compte aprĂšs plusieurs Ă©checs, dont la durĂ©e augmente exponentiellement en fonction du nombre de tentatives dans un laps de temps dĂ©terminĂ© ; cette durĂ©e soit supĂ©rieure Ă une minute aprĂšs cinq tentatives Ă©chouĂ©es, et permette de rĂ©aliser au maximum 25 tentatives par 24 heures ; et/ou
– un mĂ©canisme dĂ©terminant un nombre maximal de tentatives autorisĂ©es dans un dĂ©lai donnĂ© (par exemple, 10 essais par heure) ; et/ou
– un mĂ©canisme permettant de se prĂ©munir contre les soumissions automatisĂ©es et intensives de tentatives (par exemple : mise en Ćuvre de « captcha ») ; et/ou
– un blocage du compte aprĂšs un nombre d’authentifications Ă©chouĂ©es consĂ©cutives au plus Ă©gal Ă 10, assorti d’un mĂ©canisme de dĂ©blocage proportionnel aux risques que les personnes fassent l’objet d’une usurpation d’identitĂ©.
Le choix de la solution doit ĂȘtre opĂ©rĂ© en prenant en compte la vraisemblance d’une attaque par dĂ©ni de service, qui aurait pour objet de rendre les comptes inaccessibles, et de sa gravitĂ© pour les utilisateurs.
– Cas n° 3 : code de dĂ©verrouillage
Quand l’authentification s’appuie sur un matĂ©riel dĂ©tenu par la personne, la complexitĂ© Ă fixer dans la politique de mots de passe doit permettre d’assurer l’Ă©quivalent d’une entropie d’au moins 13 bits.
Exemple : la taille du code personnel doit ĂȘtre au minimum de 4 chiffres dĂ©cimaux.
L’authentification ne peut concerner qu’un dispositif matĂ©riel dĂ©tenu en propre par la personne, Ă savoir uniquement les cartes Ă puce et dispositifs contenant un certificat Ă©lectronique ou une paire de clĂ©s dĂ©verrouillable par mot de passe, ou tout autre mĂ©canisme technique apportant un mĂȘme niveau de sĂ©curitĂ©.
Un blocage du dispositif doit ĂȘtre mis en Ćuvre aprĂšs un nombre d’authentifications Ă©chouĂ©es consĂ©cutives au plus Ă©gal Ă 3.
3.3. Modalités de conservation des mots de passe
Le mot de passe ne doit jamais ĂȘtre stockĂ© en clair par le responsable de traitement. Lorsqu’il est conservĂ©, tout mot de passe utile Ă la vĂ©rification de l’authentification doit ĂȘtre prĂ©alablement transformĂ© au moyen d’une fonction cryptographique spĂ©cialisĂ©e, non rĂ©versible et sĂ»re (c’est-Ă -dire utilisant un algorithme public rĂ©putĂ© fort dont la mise en Ćuvre logicielle est exempte de vulnĂ©rabilitĂ© connue), intĂ©grant un « sel » et des paramĂštres relatifs aux coĂ»ts en temps et/ou en mĂ©moire nĂ©cessaires Ă son attaque. On entend par « sel » une donnĂ©e supplĂ©mentaire ajoutĂ©e systĂ©matiquement aux donnĂ©es devant ĂȘtre hachĂ©es (ici, les mots de passe) afin d’empĂȘcher que deux informations identiques donnent la mĂȘme valeur hachĂ©e sur deux systĂšmes informatiques diffĂ©rents. Utiliser un sel limite la possibilitĂ© qu’un attaquant dĂ©duise le mot de passe d’un utilisateur en consultant l’une des nombreuses bases de donnĂ©es de couples « mot de passe sans sel/valeur hachĂ©e » prĂ©calculĂ©s qui sont disponibles sur internet.
Le sel devrait ĂȘtre gĂ©nĂ©rĂ© alĂ©atoirement et avoir une longueur minimale de 128 bits. Il est gĂ©nĂ©rĂ© pour chaque utilisateur et stockĂ© dans la mĂȘme base de donnĂ©es que les mots de passe. Les diffĂ©rents Ă©lĂ©ments (taille de sel, algorithmes et paramĂštres) devront ĂȘtre rĂ©guliĂšrement mis Ă jour en fonction des risques et avancĂ©es technologiques.
La mise en Ćuvre d’un protocole de type PAKE (« Password Authenticated Key Exchange »), public et prouvĂ© sĂ»r, garantissant la vĂ©rification du mot de passe sans qu’il soit transmis en clair au serveur pour vĂ©rification est conseillĂ©e : ce type de solution permet, d’une part, de ne jamais exposer le mot de passe lors de la transaction et, d’autre part, de ne pas stocker les mots de passe sur le serveur, seule une fonction de vĂ©rification Ă©tant conservĂ©e Ă leur place.
Dans le cas particulier des mots de passe stockĂ©s dans une application, leur stockage devrait ĂȘtre limitĂ© aux applications de gestion de mots de passe (ou remplissant ce rĂŽle). Les mots de passe devraient alors ĂȘtre stockĂ©s sous une forme chiffrĂ©e et un mĂ©canisme de dĂ©verrouillage (par exemple via une phrase de passe maĂźtre) devrait ĂȘtre proposĂ©. Dans les autres cas, un mĂ©canisme de jeton Ă durĂ©e de vie limitĂ©e et rĂ©vocable Ă tout moment par l’utilisateur est conseillĂ©.
3.4. ModalitĂ©s de changement du mot de passe et d’information des personnes
Le responsable de traitement doit permette Ă la personne concernĂ©e de procĂ©der elle-mĂȘme, de façon autonome, au changement de son mot de passe. Dans ce cas, les rĂšgles affĂ©rentes Ă la crĂ©ation de mots de passe s’appliquent.
Les modalitĂ©s dĂ©crites plus haut quant Ă l’envoi de mots de passe Ă l’utilisateur par voie postale ou Ă©lectronique, s’appliquent Ă©galement Ă son renouvellement.
3.4.1. Renouvellement périodique du mot de passe
Les responsables de traitement ne devraient plus imposer de modification pĂ©riodique des mots de passe Ă l’ensemble de leurs utilisateurs. Une procĂ©dure de modification pĂ©riodique reste cependant nĂ©cessaire pour les comptes Ă privilĂšge (comptes d’administration) ; une pĂ©riodicitĂ© pertinente et raisonnable sera Ă dĂ©finir en fonction des risques.
3.4.2. Renouvellement du mot de passe sur demande de l’utilisateur
Si le renouvellement implique l’envoi d’une information (par exemple : lien web, mot de passe temporaire communiquĂ© par courriel ou tĂ©lĂ©phone), celui-ci doit s’effectuer via un canal prĂ©alablement validĂ© (par exemple : adresse courriel, moyen d’identification Ă©lectronique de secours). Afin d’empĂȘcher la compromission du mot de passe par un usage malicieux de la phase de renouvellement, il ne doit pas ĂȘtre possible d’envoyer le nouveau mot de passe sur un canal de communication rĂ©cemment modifiĂ©. La durĂ©e d’embargo sur les canaux rĂ©cemment modifiĂ©s doit ĂȘtre proportionnĂ©e aux risques d’usurpation. Toute modification du canal doit ĂȘtre notifiĂ©e Ă l’utilisateur sur l’ensemble des canaux de communication validĂ©s, y compris celui ayant fait l’objet d’une modification, afin qu’il puisse ĂȘtre alertĂ© si cette modification n’est pas de son fait.
Lorsqu’une rĂ©initialisation demandĂ©e par l’utilisateur dĂ©clenche l’envoi d’une information sur un canal prĂ©alablement validĂ©, l’utilisateur devrait simplement ĂȘtre informĂ© du fait qu’une demande de validation sera envoyĂ©e, sans lui confirmer l’existence du compte la validitĂ© du canal.
Si le renouvellement fait intervenir un ou plusieurs éléments supplémentaires (numéro de téléphone, adresse postale, réponse à une question, etc.), il convient que :
– les modalitĂ©s permettant d’identifier que la personne demandant le renouvellement est la personne dĂ©tentrice du compte ne reposent pas sur une rĂ©ponse Ă une question relative Ă des informations habituellement publiques (par exemple : des informations accessibles Ă de nombreuses personnes sur les rĂ©seaux sociaux telles que le nom des parents, le lieu d’Ă©tudes, le nom des animaux de compagnie, etc.) ;
– ces Ă©lĂ©ments ne sont pas conservĂ©s dans le mĂȘme espace de stockage que l’Ă©lĂ©ment de vĂ©rification du mot de passe, Ă moins d’ĂȘtre conservĂ©s sous forme chiffrĂ©e Ă l’aide d’un algorithme public rĂ©putĂ© fort, et que la sĂ©curitĂ© de la clĂ© de chiffrement soit assurĂ©e ;
– afin de prĂ©venir les tentatives d’usurpation s’appuyant sur le changement de ces Ă©lĂ©ments, la personne doive ĂȘtre immĂ©diatement notifiĂ©e de leur modification par les moyens de communications identifiĂ©s.
La personne concernĂ©e devrait avoir accĂšs Ă une interface lui permettant de saisir un nouveau mot de passe. La validitĂ© de la session de cette interface ne doit pas excĂ©der 24 heures, et les liens de renouvellement doivent ĂȘtre Ă usage unique. Tout nouveau lien gĂ©nĂ©rĂ© devrait rĂ©voquer les liens prĂ©cĂ©dents.
3.4.3. Renouvellement des mots de passe et information des usagers en cas de compromission
Lorsqu’une atteinte Ă la confidentialitĂ© des mots de passe ou, plus gĂ©nĂ©ralement une atteinte Ă la sĂ©curitĂ© susceptible d’engendrer la compromission de comptes utilisateurs, a Ă©tĂ© dĂ©tectĂ©e, le responsable de traitement informe sans dĂ©lai la personne concernĂ©e et lui permet de renouveler son mot de passe immĂ©diatement.
Le responsable de traitement doit Ă©valuer le risque d’usurpation de compte et ses impacts afin de dĂ©cider de la nĂ©cessitĂ© de mesures particuliĂšres (par exemple : blocage temporaire des comptes concernĂ©es ou mise en Ćuvre d’un mĂ©canisme supplĂ©mentaire d’identification de l’usager).
DĂšs lors qu’il existe une suspicion de violation de son mot de passe, le responsable de traitement doit imposer Ă la personne concernĂ©e de le modifier lors de sa prochaine connexion, et lui recommander de veiller Ă changer les mots de passe des Ă©ventuels services pour lesquels elle aurait utilisĂ© ce mĂȘme mot de passe.
Lorsqu’une information complĂ©mentaire est utilisĂ©e (cas n° 3), celle-ci doit Ă©galement ĂȘtre renouvelĂ©e dĂšs lors que sa confidentialitĂ© n’est plus garantie.
Enfin, concernant les donnĂ©es de renouvellement, les questions secrĂštes et leurs rĂ©ponses doivent Ă©galement ĂȘtre renouvelĂ©es en cas d’atteinte Ă leur confidentialitĂ©.
3.5. Journalisation
Les activitĂ©s d’authentification des utilisateurs et de manipulation de leurs secrets, par eux-mĂȘmes ou des tiers, doivent normalement faire l’objet d’une journalisation respectant les recommandations de la CNIL en la matiĂšre. Les mots de passe ainsi que les identifiants non reconnus ne doivent pas apparaĂźtre dans les journaux.
Article 2
La dĂ©libĂ©ration n° 2017-012 du 19 janvier 2017 portant adoption d’une recommandation relative aux mots de passe est abrogĂ©e.
Le cas d’usage n° 3 qui y Ă©tait prĂ©vu (c’est-Ă -dire, le cas correspondant Ă une information secrĂšte de 7 caractĂšres et un mot de passe d’au moins 5 caractĂšres) n’est plus recommandĂ© par la Commission. Les responsables de traitement qui auraient mis en Ćuvre ce cas d’usage devraient faire Ă©voluer leur politique de mots de passe vers un autre cas. La Commission tiendra compte du dĂ©lai nĂ©cessaire pour mettre en Ćuvre les changements nĂ©cessaires.
La présente délibération sera publiée au Journal officiel de la République française.
Date et signature(s)
La présidente,
M.-L. Denis