6 min

Amélioration continue – Comment le contre-productif se maintient en « best practice » de sécurité ?

Introduction

2020 – La sécurité X.0 n’a pas résolu la question du mot de passe. La « Politique LCR » – Longueur minimale, Complexité, et Renouvellement régulier – intuitive certes, perdure malgré les constats qui la remette en cause. Avons-nous mesuré son efficacité ? Face aux constats, quelles sont les solutions ? Et surtout, quels sont les facteurs comportementaux qui contribuent au statu quo ?

Une vérité qui dérange

Quel était l’objectif ?

La politique LCR est uniformément adoptée dans la majeure partie des grandes entreprises. Elle est même soutenue par plusieurs institutions françaises : CERTA [1], CNIL [2], ANSSI « Renouvelez vos mots de passe avec une fréquence raisonnable. Tous les 90 jours est un bon compromis pour les systèmes contenant des données sensibles » [3], ANS [4].

« Un bon mot de passe est avant tout un mot de passe « fort », c’est à dire difficile à retrouver même à l’aide d’outils automatisés ». Il peut éventuellement être défini par sa force : « La force d’un mot de passe dépend de sa longueur et du nombre de possibilités existantes pour chaque caractère le composant. » [3]. Citation de l’ANSSI qu’il est impératif de compléter par : « et de la non prédictibilité des caractères ».

Mais cette politique LCR est-elle efficace ? Favorise-t-elle le choix de mots de passe « forts » ?

Les « Faits »

Nous avons réalisé le « cassage » des mots de passe et des historiques de mots de passe de 5298 utilisateurs réels. Nos résultats sont équivalents à ceux publiés dans des documents de recherche [5] [6].

  • 5298 comptes disposant d’au moins 2 historiques ;
  • 33188 hashs au total ;
  • 88% des hashs cassés en moins de 10 jours.
  Comportements identifiés sur le mot de passe % hashs cassés
1 Commencent par une majuscule : A 58%
3 Majuscule est suivie de minuscules : Aaaa… 48%
4 Se terminent par 1, 2, 3 ou 4 chiffres 72%
5 Répondent aux critères (1) et (2) et (3) 33%

 

D’après le critère de force, les mots de passe et leur structure ne devraient pas être prédictibles. L’objectif n’est pas atteint.

Comment expliquer ce constat ?

Deux raisons qui font que l’utilisateur n’est pas responsable :

  1. Fatigué des incohérences qui émergent en l’absence de SSO (gestion de nombreux mots de passe, renouvellements non synchronisés, « timing » inapproprié… [7]), il finira par orienter son choix vers des mots de passe faciles à retenir et « conformes » à la politique LCR : « Internet2018 » ou « Judith2612 »
  2. « Le tout n’est pas la somme des parties »

Lors de la création d’un mot de passe, les indications sont une « somme d’informations » dont le sens global a disparu.

Tant que l’efficacité d’une règle de sécurité n’est pas évaluée il est impossible de lui appliquer une démarche d’amélioration continue.

La sensibilisation ne résoudra pas le problème car celui-ci ne provient pas d’une incompréhension de la politique LCR.

Si la cause du problème ne se limite pas à la compréhension de la politique [8], alors la sensibilisation seule ne la rendra pas plus efficace.

Quelles solutions ?

Nous affranchir du mot de passe via une authentification multi-facteur serait une grande avancée mais ce mécanisme est coûteux et ne peut s’appliquer dans toutes les situations (SI « legacy » ou industriels par exemple).

Comme la disparition du mot de passe ne semble pas se profiler, la démarche d’amélioration continue devrait entraîner un changement radical de la politique LCR :

  1. Désactiver le renouvellement régulier [9]car il incite à la simplification ;
  2. Désactiver l’exigence de complexité afin de sortir des structures prédictibles « Aaaaaa1234 » ;
  3. Le Single Sign-On, pour éviter la « password fatigue » [7] et inciter une deuxième fois à la simplification ;
  4. Exiger une augmentation de la longueur du mot de passe, contrepartie de la suppression des deux premières règles ;
  5. Former les employés sur la « passphrase » pour éviter « correcthorsebatterystapple » [10] [11];
  6. Mettre à disposition des gestionnaires de mot de passe ;
  7. Casser régulièrement les bases de mots de passe internes pour détecter les mots de passe « faibles » et orienter leur changement à l’aide des sciences comportementales.

 

INSERER IMAGE

XKCD 936 Solution intuitive mais qui doit aussi être évitée [11] .

SSO exclu, le coût de l’ensemble des mesures est raisonnable. Au regard des risques encourus et des coûts, comment expliquer le maintien de la politique LCR dans les entreprises ?

De l’intention à l’action

Plusieurs facteurs comportementaux renforcent le statu quo :

  • L’influence du régulateur, « l’effet de halo » :

L’absence d’évolution de la politique LCR recommandée par les institutions nationales : ANSSI, CNIL… Un RSSI se « protégera » en appliquant les directives nationales.

  • La « dilution de la responsabilité » :

On considère qu’une règle est appliquée correctement parce qu’elle est définie par le RSSI, implémentée par les équipes opérationnelles, communiquée aux utilisateurs et imposée a minima lors du choix du mot de passe. Autrement dit, « Tout va bien », chaque acteur a fait sa part du travail.

Note : l’AD ne prend en compte que les critères L et C, sans autres contrôles : nom de la société, caractère incrémental…

  • Le biais de statu quo :

La politique LCR est déjà en place et nous préférons la maintenir dans sa configuration d’origine, et ce, même en possession de nouvelles informations.

  • « L’opinion identitaire » et les « coûts perdus » :

Nous avons tendance à considérer que nous incarnons nos décisions. Se dédire revient en quelques sorte à dédire notre personne et les positions que nous avons défendues. Le « coût psychologique » d’un changement de trajectoire semble supérieur au bénéfice associé.

La politique LCR a-t-elle été trop longtemps défendue pour ne plus pouvoir être remise en cause ?

Conclusion

Placer le problème « entre la chaise et l’écran » c’est dédouaner trop rapidement la sécurité informatique de sa responsabilité.

La politique LCR n’est pas adaptée au fonctionnement de notre cerveau, en effet, elle est intuitive mais basée sur des informations incomplètes. Les données présentées nous invitent à réévaluer notre opinion, à l’instar d’autres institutions : FBI [12], GCHQ [13], NIST [14].

Modifier la politique de mot de passe, c’est prendre en compte ces nouvelles informations et appliquer la démarche d’amélioration continue.

 

(par Gilles Favier)

 

Références

1 CERTA – Note d’information – Mots de passe – CERTA-2005-INF-001
2 Guide de la CNIL – 2012 – https://services-numeriques.unistra.fr/fileadmin/upload/Services_numeriques/Documents/DI/CIL/CNIL-guide-securite.mht.pdf
3 ANSSI – 01/09/2019 – https://www.ssi.gouv.fr/guide/mot-de-passe/ & https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_MDP_NoteTech.pdf
4 Autorité Nationale de Santé – https://esante.gouv.fr/sites/default/files/media_entity/documents/2019-11-20_Dossier_Information_Campagne_Cybersecurite.pdf
5 Lorrie Cranor – CMU – Measuring password guessability for an entire university https://doi.org/10.1145/2508859.2516726
6 Yinqian Zhang et al. – The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis – https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf
7 Report : Authentication, Diary study : http://nvlpubs.nist.gov/nistpubs/ir/2014/NIST.IR.7983.pdf
8 Lorrie Cranor – CMU – Do Users’ Perceptions of Password Security Match Reality? – https://www.archive.ece.cmu.edu/~lbauer/papers/2016/chi2016-pwd-perceptions.pdf
9 https://www.wsj.com/articles/the-man-who-wrote-those-password-rules-has-a-new-tip-n3v-r-m1-d-1502124118
10 XKCD – Password Strength – https://xkcd.com/936/
11 https://diogomonica.com/2014/10/11/password-security-why-the-horse-battery-staple-is-not-correct/
12 FBI Tech Tuesday: Building a Digital Defense with Passwords – https://diogomonica.com/2014/10/11/password-security-why-the-horse-battery-staple-is-not-correct/
13 GCHQ – 2015 – Password Guidance –  https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/458857/Password_guidance_-_simplifying_your_approach.pdf
14 NIST – 2017 – https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

 

Partager cet article avec un ami