Phrases de passe : la CNIL passe elle aussi en mode 2.0

Phrases de passe : la CNIL passe elle aussi en mode 2.0

Arrêtez d'en changer #BisRepetita

Avatar de l'auteur
Jean-Marc Manach

Publié dans

Droit

22/10/2021 16 minutes
25

Phrases de passe : la CNIL passe elle aussi en mode 2.0

Les nouvelles recommandations de la CNIL déconseillent, tout comme l'ANSSI, l'obligation de renouvellement périodique des mots de passe. Elle met par ailleurs en avant la sensibilisation au « cycle de vie » et l'importance de l'entropie.

Quelques jours après la publication de la V2 des recommandations de l'ANSSI « relatives à l'authentification multifacteur et aux mots de passe », la CNIL (qui y avait contribué) lance de son côté une consultation publique sur sa nouvelle recommandation (.pdf) sur les « mots de passe (et autres secrets partagés) ».

L'autorité a en effet décidé de mettre à jour sa précédente recommandation de 2017 sur les mots de passe « afin de permettre aux professionnels et aux particuliers de disposer d’outils pratiques et à l’état de l’art » : « En effet, au cours des quatre dernières années, les précédentes recommandations de la CNIL ont été à de multiples reprises confrontées à des situations d’usage concrètes et éprouvées par un grand nombre de professionnels. »

Dans son introduction, elle constate « la multiplication des attaques informatiques, qui a entraîné la compromission de bases de données entières 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 ».

Elle relève par ailleurs que « l’emploi par les utilisateurs d’un même mot de passe pour se connecter à 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 toutes mesures permettant d'assurer la sécurité des données à caractère personnel ».

Et ce, alors que « d’après une étude de Verizon de 2021, 81 % des notifications de violations de données mondiales seraient liés à une problématique de mots de passe » :

« En France, environ 60 % des notifications reçues par la CNIL depuis le début de l’année 2021 sont liés à du piratage et un grand nombre aurait pu être évité par le respect de bonnes pratiques. »

Elle rappelle à ce titre les principaux risques identifiés au cours du cycle de vie d'un mot de passe, qui reposent sur :

  • la simplicité du mot de passe ;
  • l’écoute sur le réseau afin de collecter les mots de passe transmis ;
  • la conservation en clair du mot de passe ;
  • la faiblesse des modalités de renouvellement du mot de passe en cas d’oubli (cas des questions « secrètes »)
CNIL mot de passe

Dans son communiqué, la CNIL résume sa nouvelle recommandation en précisant que par rapport à celle de 2017, le nouveau projet apporte notamment les modifications suivantes :

  • la définition d’une règle fondée sur le degré d’imprédictibilité d’un mot de passe (l’entropie) et non sur la longueur minimale de mot de passe, pour permettre une mise en place plus libre de politiques de mots de passe robustes ;
  • l’abandon de l’obligation de renouvellement des mots de passe pour les comptes utilisateurs classiques (le renouvellement reste requis pour les comptes à « privilèges », c’est-à-dire du type administrateur ou avec des droits étendus) ;
  • l’introduction d’une liste de mots de passe complexes mais connus et donc à éviter compte tenu des nouveaux schémas d’attaque ;
  • la précision de règles concernant la création et le renouvellement de mots de passe pour garantir une sécurité tout au long du cycle de vie sous forme de bonnes pratiques (gestionnaire de mot de passe, non recours à des informations évidentes).

Une entropie de 80 bits minimum

La CNIL précise que, dans sa recommandation, le terme « mot de passe » désigne « tout facteur de connaissance, 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 donc, 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. »

De manière générale, elle recommande que tout responsable de traitement « garantisse 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 » (nous y reviendrons) 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 ».

Elle considère que « d'autres moyens d’authentification, comme par exemple l'authentification à double facteur ou les certificats électroniques, offrent davantage de sécurité que le mot de passe ». Et qu'ils pourraient être requis « en fonction des risques spécifiques à certains traitements (par exemple, dans le cadre de données sensibles ou à large échelle) ou à certaines catégories d’utilisateurs (par exemple, les administrateurs informatiques) ».

Un mot de passe maître fort

En matière de gouvernance, la CNIL recommande non seulement que les organismes définissent une politique de gestion des mots de passe, qu'elle soit communiquée à toutes les personnes concernées, mais également que ces dernières « doivent être sensibilisées aux menaces et aux risques de compromission des mots de passe, ainsi qu’au comportement à adopter en cas de suspicion de compromission de ceux-ci » :

« Ces formations peuvent 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 et la nécessité de sauvegarder régulièrement la base). »

Il ne s'agit donc plus seulement de les conseiller sur les critères de choix d'un bon mot de passe, mais bien de les sensibiliser à leurs modèles de menace, ainsi qu'à la bonne gestion de son cycle de vie.

L'entropie, ou degré d’imprédictibilité

En guise de préambule, et avant d'aborder les « modalités opérationnelles de l’utilisation de mots de passe », la CNIL rappelle qu'« on appelle "entropie" la quantité de hasard contenue dans un système [l'entropie est un terme polysémique, cette définition est celle qui prévaut en théorie de l'information, ndlr]. 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 » :

« 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 8192, 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. »

Or, 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 ou des prénoms, 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 », etc.).

Dès lors, lorsque les utilisateurs ont la liberté de choisir 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 (voir aussi le calculateur de l'ANSSI) :

« En effet, si on s’attend à ce que les utilisateurs emploient 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 [et] 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. »

De 50 caractères (minimum) à quelques centaines (maximum)

La Commission recommande de fixer une taille maximale pour les champs des mots de passe « 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 […]. 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 », elle recommande par ailleurs de « ne pas mettre en œuvre de mécanisme ayant pour objet ou effet d'interdire aux utilisateurs de coller un mot de passe dans les champs de saisie des mots de passe, tant lors de la création du mot de passe que de l'authentification ».

De plus, et à l'exception des envois par voie postale, la CNIL recommande que les mots de passe « ne soient jamais communiqués à l'utilisateur en clair, notamment par courrier électronique. Seuls des mots de passe temporaires ou à usage unique devraient être communiqués en clair aux utilisateurs ».

Ces derniers devraient en outre avoir « une durée d'expiration courte, d'au plus 24 heures ». En tout état de cause, et « dans la mesure du possible, le responsable de traitement doit conseiller et guider l’utilisateur dans la création de son mot de passe » :

« 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 tous les cas, la CNIL recommande de « ne pas accepter les mots de passe connus comme étant couramment utilisé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é). »

Mot de passe seul : au minimum 7 mots

En cohérence avec les nouvelles recommandations de l’ANSSI, la Commission décrit les exigences minimales permettant de se conformer à sa propre recommandation. Le premier fait reposer la sécurité principalement sur le mot de passe, et impose par conséquent des exigences importantes en termes de taille et de complexité du mot de passe, susceptibles d’assurer l'équivalent d'une entropie d'« au moins 80 bits ».

La CNIL en donne trois exemples :

  • 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.
  • 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.
  • les phrases de passe fondées sur des mots de la langue française doivent être composées d’au minimum 7 mots.

La robustesse de cette authentification reposant sur la qualité intrinsèque du mot de passe, le responsable de traitement devra être « particulièrement vigilant quant à la qualité des mots de passe de ses utilisateurs ».

Au minimum 5 mots, ou 15 chiffres

Quand l'authentification prévoit un mécanisme de restriction de l'accès au compte (via un captcha, le blocage du compte en cas d'authentifications échouées, ou la temporisation après plusieurs échecs – « supérieure à 1 minute après 5 tentatives échouées », et d'« au maximum 25 tentatives par 24 heures », précise la CNIL), l'entropie peut être ramenée à « au moins 50 bits », tel que :

  • 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 ;
  • les phrases de passe fondées sur des mots de la langue française doivent être composées d’au minimum 5 mots ;
  • les mots de passe doivent être composés d'au minimum 15 chiffres.

Le choix de la solution devra ê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 ».

8 chiffres décimaux ou 7 chiffres hexadécimaux

Quand l'authentification comprend la fourniture d’une information complémentaire en sus de la mise en place d’un mécanisme de restriction d’accès, la complexité doit permettre d’assurer, « au minimum, une entropie de 27 bits » :

  • la taille du mot de passe doit être au minimum de 8 chiffres décimaux ;
  • les mots de passe doivent être composés d'au minimum 7 chiffres hexadécimaux (chiffres décimaux et lettres de A à F, sans distinction entre majuscules et minuscules).

À quoi il convient d'ajouter 23 bits supplémentaires d'entropie via « un identifiant de 7 chiffres décimaux générés aléatoirement » (ou 6 chiffres hexadécimaux) qui :

  • ne soit connu que de la personne et du responsable de traitement (et qui devra être renouvelé en cas de violation de sa confidentialité),
  • soit « en principe exclusivement dédié à un seul service », et puisse être renouvelé dans certains cas,
  • soit vérifié par la mise en œuvre d'une empreinte numérique (« device fingerprinting ») sur un appareil défini par l’utilisateur comme étant de confiance, ce « qu'il peut à tout moment révoquer ».

Du fait de la « collecte d’une information complémentaire relative au terminal de l’usager », ce cas ne devrait être choisi, « dans une démarche de protection de la vie privée dès la conception et par défaut », qu’« après une évaluation de sa proportionnalité pour le traitement considéré ».

Code de déverrouillage plus 4 chiffres décimaux

Quand l'authentification s'appuie sur un dispositif matériel détenu 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é », la complexité doit « permettre d’assurer l'équivalent d'une entropie d'au moins 13 bits ».

Dès lors, « le code personnel doit être au minimum de 4 chiffres décimaux ». De plus, un blocage du dispositif devra être mis en œuvre « après un nombre d'authentifications échouées consécutives au plus égal à 3 ».

Un sel généré aléatoirement de 128 bits minimum

La CNIL estime au surplus que « le mot de passe ne doit jamais être stocké en clair par le responsable de traitement », et recommande que « tout mot de passe utile à la vérification de l'authentification soit préalablement transformé au moyen d'une fonction cryptographique spécialisée non réversible et sûre (...) intégrant un sel et des paramètres relatifs aux coûts en temps et/ou en mémoire » :

« La Commission estime que le sel doit être généré aléatoirement et avoir en principe une longueur minimale de 128 bits. Il doit être généré pour chaque utilisateur et peut être stocké dans la même base de données. »

N'imposez plus de renouvellement périodique des mots de passe

En cas de compromission, la CNIL recommande que le responsable de traitement « permette à la personne concernée de procéder elle-même et de façon autonome au changement de son mot de passe ».

De plus, elle « ne recommande pas que le responsable de traitement veille à imposer un renouvellement périodique des mots de passe de l'ensemble de ses utilisateurs ». Elle estime cela dit qu'une procédure de renouvellement périodique « reste cependant nécessaire pour les comptes à privilège (comptes d’administration) », dont la périodicité devra être « pertinente et raisonnable [...] en fonction des risques ».

La procédure de renouvellement devra s'effectuer « via un canal préalablement validé (p.ex.: adresse courriel, moyen d’identification électronique de secours) ». De plus, et « 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 récemment modifié ».

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.) », la Commission considère en outre que :

  • les modalités permettant d'identifier que la personne demandant le renouvellement est bien la détentrice du compte ne doit pas reposer sur une réponse à une question relative à des informations habituellement publiques (« p.ex.: 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 doivent pas être 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 doit être immédiatement notifiée de leur modification par les moyens de communications identifiés.

Un appel à commentaires d'ici le 3 décembre

Souhaitant permettre au plus grand nombre de s’exprimer sur les travaux réalisés, la CNIL invite tous les acteurs (publics, privés ou du secteur associatif) concernés par la recommandation à lui faire part de leurs observations, « qu’ils soient ou non professionnels de la sécurité des systèmes d’information ».

Elle espère notamment pouvoir identifier les « difficultés techniques » de mise en œuvre de ses recommandations, les « nouveaux risques » qui ne seraient pas couverts, des mesures alternatives à l’empreinte numérique de l’appareil, ainsi que les « outils pratiques » susceptibles d'aider à la prise en compte de cette recommandation.

Et ce, d'ici au 3 décembre 2021, pour lui permettre de publier sa recommandation définitive début 2022.

Écrit par Jean-Marc Manach

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une entropie de 80 bits minimum

Un mot de passe maître fort

L'entropie, ou degré d’imprédictibilité

De 50 caractères (minimum) à quelques centaines (maximum)

Mot de passe seul : au minimum 7 mots

Au minimum 5 mots, ou 15 chiffres

8 chiffres décimaux ou 7 chiffres hexadécimaux

Code de déverrouillage plus 4 chiffres décimaux

Un sel généré aléatoirement de 128 bits minimum

N'imposez plus de renouvellement périodique des mots de passe

Un appel à commentaires d'ici le 3 décembre

Fermer

Commentaires (25)


Ah pas d’obligation d’intégré (pour les site) une vérification périodique des hash sur have i been pwnd ? Dommage, ca aurais été cool.



SIaelrod a dit:


Ah pas d’obligation d’intégré (pour les site) une vérification périodique des hash sur have i been pwnd ? Dommage, ca aurais été cool.




Une recommandation est un instrument de “droit souple”, qui fixe des règles “minimales” de bonnes pratiques. Par nature, elle ne peut pas être contraignante (donc pas d’“obligation” possible dedans). Les responsables de traitement sont bien évidemment encouragés à “faire mieux” ; ils peuvent éventuellement faire “autrement”, voire (un peu) “moins bien”, si la situation le justifie (lire : s’ils peuvent le justifier auprès des services de la CNIL lors d’un contrôle par ceux-ci :D ).


Je rajouterai une petite précision avec l’entropie. Il faut se méfier des valeurs parfois calculés. Par exemple un mot de passe du genre P@ssword1234 a certaines une très bonne entropie (selon la définition de la CNIL) mais d’un point de vue pratique, c’est une aberration en terme de sécurité. De toute façon, la définition assume une distribution aléatoire uniforme ce qui n’est pas toujours vrai pour un mot de passe.



Perso, j’utilise un autre indicateur qui est l’entropie de Shannon. Les valeurs trouvées sont souvent plus faible, mais elle a le mérite de prendre en compte la fréquence d’occurrence dans le calcul. Et pour le coup a un sens beaucoup plus physique/mathématique. Celui de la CNIL ressemble juste à une loi de dénombrement en logarithme à base 2.



BlackLightning a dit:


Je rajouterai une petite précision avec l’entropie. Il faut se méfier des valeurs parfois calculés. Par exemple un mot de passe du genre P@ssword1234 a certaines une très bonne entropie (selon la définition de la CNIL)




Ben non, justement : “P@ssword” n’est pas une séquence de lettres choisies aléatoirement, ce qui fait que l’entropie est plus faible que le “dénombrement en log_2” que vous évoquez. De même si vous choisissez des chiffres qui correspondent à votre date de naissance (ce qui n’a rien à voir avec la fréquence d’occurrence).



Il est bien marqué dans l’article (et dans la recommandation) que :



Dès lors, lorsque les utilisateurs ont la liberté de choisir 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é »


tu devrais relire le paragraphe consacré à l’entropie, ton objection y est donnée.


anagrys

tu devrais relire le paragraphe consacré à l’entropie, ton objection y est donnée.



(reply:1909468:fp)

Je considère qu’il y a deux entropies dans cette histoire. L’entropie du générateur et l’entropie du mot de passe.
Pour un générateur aléatoire à distribution uniforme G, on peut y associer son entropie comme étant défini par le log2(max. combinaison possible). (Entropie de Shannon dans le cas d’une distribution uniforme).




Mais par contre, l’entropie du générateur aléatoire ne donne pas l’entropie du mot de passe. Si on prends le générateur donné dans l’exemple, il est mathématiquement possible d’avoir 0000, 1111, 2222… Et là, l’entropie du mot de passe généré n’est absolument pas bonnes du tout.



Ce que je veux pointer, c’est qu’il y a une différence entre l’entropie du générateur et celui du mot de passe si le mot de passe n’est pas fait de symboles distribués uniformément. Ainsi dans l’exemple de la CNIL, la série de chiffres 0123 (ou une variation de la position spatial des chiffres) à la meilleur entropie. A contrario 0000 ou 1111 à une mauvaise entropie, et ceux malgré un générateur aléatoire uniforme disposant d’une bonne entropie.



fp a dit:


Une recommandation est un instrument de “droit souple”, qui fixe des règles “minimales” de bonnes pratiques. Par nature, elle ne peut pas être contraignante (donc pas d’“obligation” possible dedans). Les responsables de traitement sont bien évidemment encouragés à “faire mieux” ; ils peuvent éventuellement faire “autrement”, voire (un peu) “moins bien”, si la situation le justifie (lire : s’ils peuvent le justifier auprès des services de la CNIL lors d’un contrôle par ceux-ci :D ).




Oui en effet mais recommender une vérification hebdomadaire ou mensuelle des hash sur have i been pwned ou equivalent aurais eter bien (histoire d’éviter mes mots de passe fort deja dans une brèche et remplacer les mots de passe s’il apparaissait dans une brèche (car quelqu’un aurait décidé de ne pas suivre les recommandations et utiliser le meme mots de passé partout)


Pas de Keepass (ou autre) fournit au taf ?



fp a dit:


Une recommandation est un instrument de “droit souple”, qui fixe des règles “minimales” de bonnes pratiques. Par nature, elle ne peut pas être contraignante (donc pas d’“obligation” possible dedans). Les responsables de traitement sont bien évidemment encouragés à “faire mieux” ; ils peuvent éventuellement faire “autrement”, voire (un peu) “moins bien”, si la situation le justifie (lire : s’ils peuvent le justifier auprès des services de la CNIL lors d’un contrôle par ceux-ci :D ).




Ils auraient pu intégrer ce check style HIBP aux recommandations, le NIST l’a bien fait. On aura sans doute ça dans 10 ans.




ilink a dit:


Au bureau, ils ont modifié firefox pour qu’il ne stocke plus les Mdp.. résultat ça agace les gens qui les mettent en note sur le bureau de Windows.




Bravo à eux. Il faut faire très attention avec les règles en matière de mdp : ce qui sur le papier augmente la sécurité peut en réalité la diminuer à cause du facteur humain (trop contraignant donc on adopte une pratique pire que si la règle n’était pas là, comme dans ton cas).
Pour ton cas je dirais qu’il manque une alternative intelligente : si les gens utilisent le navigateur pour stocker les mdp mais que ça ne convient pas, alors il faut leur fournir une autre solution de stockage, tel qu’un gestionnaire de mdp.



SIaelrod a dit:


Oui en effet mais recommender une vérification hebdomadaire ou mensuelle des hash sur have i been pwned ou equivalent aurais eter bien (histoire d’éviter mes mots de passe fort deja dans une brèche et remplacer les mots de passe s’il apparaissait dans une brèche (car quelqu’un aurait décidé de ne pas suivre les recommandations et utiliser le meme mots de passé partout)




Ce n’est pas utile si le mot de passe est “salé” sur chaque site : le hash est alors différent, et surtout le mot de passe initial ne peut pas facilement être retrouvé par “rainbow table”.



fp a dit:


Ce n’est pas utile si le mot de passe est “salé” sur chaque site : le hash est alors différent, et surtout le mot de passe initial ne peut pas facilement être retrouvé par “rainbow table”.




C’est utile, car ce qui est dans les hash de have i been pwned est considéré comme ayant fuité. Donc une énumération reste possible. Et s’il est dans hibp, il est potentiellement relié à un nom d’utilisateur, donc même avec un rate limit, ce n’est pas une bonne idée de le garder.


tdelmas


fp a dit:


Ce n’est pas utile si le mot de passe est “salé” sur chaque site : le hash est alors différent, et surtout le mot de passe initial ne peut pas facilement être retrouvé par “rainbow table”.




C’est utile, car ce qui est dans les hash de have i been pwned est considéré comme ayant fuité. Donc une énumération reste possible. Et s’il est dans hibp, il est potentiellement relié à un nom d’utilisateur, donc même avec un rate limit, ce n’est pas une bonne idée de le garder.


Je rejoins fp sur un point, je ne comprends pas comment on fait une vérification hebdomadaire ou mensuel.



Même si Have I Been Pwned fournit une liste de hash de mots de passe compromis, les sites qui font la vérification n’ont pas directement les hashs des mots de passes de leurs utilisateurs. Ils stockent des hash salés. Le seul moment où ils ont le mot de passe, c’est lorsqu’il transite au login ou à la création du mot de passe.



Je peux donc visualiser comment mettre en place une vérification lors de création/changement du mot de passe. Mais comment mettre en place une vérification hebdomadaire ou mensuel ?


Amabaka

Je rejoins fp sur un point, je ne comprends pas comment on fait une vérification hebdomadaire ou mensuel.



Même si Have I Been Pwned fournit une liste de hash de mots de passe compromis, les sites qui font la vérification n’ont pas directement les hashs des mots de passes de leurs utilisateurs. Ils stockent des hash salés. Le seul moment où ils ont le mot de passe, c’est lorsqu’il transite au login ou à la création du mot de passe.



Je peux donc visualiser comment mettre en place une vérification lors de création/changement du mot de passe. Mais comment mettre en place une vérification hebdomadaire ou mensuel ?


Pour faire une “vérification hebdomadaire ou mensuel”, c’est effectivement uniquement au login, donc pas de vérification si la personne ne se connecte pas, et pas de vérification systématique non plus.



Pour moi l’implémention est du type “au login, si la dernière vérification date de plus de X jours, vérifier avec Have I Been Pwned” (avec donc mise à jour régulière des listes), ou une mise à jour des listes une fois par semaine/mois et le premier login suivant pour tous déclenchera une vérification.


tdelmas

Pour faire une “vérification hebdomadaire ou mensuel”, c’est effectivement uniquement au login, donc pas de vérification si la personne ne se connecte pas, et pas de vérification systématique non plus.



Pour moi l’implémention est du type “au login, si la dernière vérification date de plus de X jours, vérifier avec Have I Been Pwned” (avec donc mise à jour régulière des listes), ou une mise à jour des listes une fois par semaine/mois et le premier login suivant pour tous déclenchera une vérification.


Je vois, merci pour les explications.


En complément de la recommandation de la CNIL sur les sels, on peut mentionner également les fonctions de dérivations de clés (PBKDF2, [bs]crypt, Argon2…), qui ont l’avantage d’affaiblir les attaques par brutes-forces du CPU à l’ASIC en passant par les GPUs.



BlackLightning a dit:


En complément de la recommandation de la CNIL sur les sels, on peut mentionner également les fonctions de dérivations de clés (PBKDF2, [bs]crypt, Argon2…), qui ont l’avantage d’affaiblir les attaques par brutes-forces du CPU à l’ASIC en passant par les GPUs.




La recommandation mentionne justement la nécessité d’utiliser une fonction ayant un coût en temps et/ou en mémoire paramétrable. Je suppose qu’elle se garde de donner des exemples pour éviter un effet boomerang si demain un exemple donné s’avère inadapté ou vulnérable mais que des devs ou entreprises se basent toujours sur ce texte pour choisir la fonction à utiliser, voire iront le brandir en cas de problème.



Tiens, exemple : https://twitter.com/TerahashCorp/status/1155129705034653698
Et pourtant OWASP recommande Argon2id, donc qui croire ?



BlueSquirrel a dit:


La recommandation mentionne justement la nécessité d’utiliser une fonction ayant un coût en temps et/ou en mémoire paramétrable.




De mon point de vue, mentionner des algorithmes et leurs paramètres recommandées sur la base de travaux universitaires me semble pertinent.




Je suppose qu’elle se garde de donner des exemples pour éviter un effet boomerang si demain un exemple donné s’avère inadapté ou vulnérable mais que des devs ou entreprises se basent toujours sur ce texte pour choisir la fonction à utiliser, voire iront le brandir en cas de problème.




La théorie est que la sécurité est en constamment en évolution. Pour moi, quand on bosse dans ce domaine, on se doit de ce tenir au courant même si on n’est pas un PhD en crypto. Donc dire “oui mais la CNIlL/ANSSI/NIST a dit que c’était sécurisé” et utiliser de telles outils sans comprendre les limites revient à manipuler un sabre-laser sans être un Jedi.
Et ceci dit, rien n’empêche ce genre d’organisme d’annuellement mettre à jour leur recommandation. Selon moi, avant de blâmer les organismes, je regarderai du coté des devs (modulo les donneurs d’ordres).




Tiens, exemple : https://twitter.com/TerahashCorp/status/1155129705034653698 Et pourtant OWASP recommande Argon2id, donc qui croire ?




Honnêtement, leur recommandation me semble un peu légère au vu des derniers travaux de recherches (de mémoire, hein. Je me fais peut-être vieille aussi) bien qu’un peu faible selon moi. (Je préfère 2000).
La bonne source est de fouiller dans les articles universitaires. A défaut suivre les recommandations de cryptographes renommées. Également, regarder ce qui fait dans d’autres soft open-source (e.g., Cryptsetup). Plus facile à dire qu’à faire, je sais. Mais ce n’est ni plus ni moins qu’une forme de veille techno.



fp a dit:


Ce n’est pas utile si le mot de passe est “salé” sur chaque site : le hash est alors différent, et surtout le mot de passe initial ne peut pas facilement être retrouvé par “rainbow table”.




J’ai eu une fois un service qui refusait un mots de passe car lister sur have i been pwned


Est-ce que ces recommandations ont une valeur juridique ? Par exemple un site qui se fait hacker sa base de données et voler des données personnes, il doit avertir la CNIL. si on s’aperçoit que le mot de passe est stocké en clair, on peut se retourner contre le site car il n’a pas suivi ces recommandations, ou c’est uniquement à titre informatif ?


C’est du “droit souple” mais c’est effectivement un instrument de référence pour évaluer la conformité d’un responsable de traitement, en termes de mesures de sécurisation des données.
Concernant les mots de passe en clair, cela fait longtemps que la CNIL sanctionne cette pratique comme un manquement aux règles de sécurité (au titre de l’art. 32 RGPD). En termes de recommandations, on peut également citer la “liste des horreurs” de l’OWASP (les 10 pires failles de sécurité des sites web), qui sert à éduquer les responsables de traitement et définit par contraste un corpus de bonnes ptratiques auquel il devient difficile de prétendre déroger.


Bonjour,



Est-ce qu’il y a une source pour la version de 2021 ? Je ne trouve pas de lien sur l’article …


Merci, je vois qu’elle a été ajouté au début de l’article :pouce_vert_le_haut: