Les mots de passe, ces ignominies

Les mots de passe, ces ignominies

L'état de l'art

Devenant relativement critiques ces derniers temps, les mots de passe sont au cœur de notre identité numérique. Quasiment chaque service que nous utilisons nous en demande un, même si l'on perçoit une migration vers l'authentification forte qui progresse à bon rythme : validation de la connexion par email, par SMS à l'aide d'un OTP, ou via une application telle que Google Authenticator.

Nous le savions depuis longtemps, mais nous fermions les yeux : nos mots de passe sont trop "faibles". Mais est-ce vraiment de notre faute ? Pourquoi utilisons-nous des mots de passe trop "simples", facile à retenir ?

Les besoins n'étaient pas les mêmes dans les débuts de leur utilisation, Morris et Thompson en parlaient en 1979 : ils servaient uniquement à protéger l'accès à des ressources en réseau, afin de garantir que seuls les utilisateurs légitimes pouvaient y accéder. Nous avions donc uniquement besoin de se protéger des attaques en ligne, c'est à dire de se protéger contre une personne qui essaie les mots de passe un par un directement sur le service en question.

Avec l’essor d'Internet, les besoins aujourd'hui ont changés. Nous avons en moyenne une dizaine de sites web sur lesquels nous nous connectons régulièrement. Si l'on compte les connexions moins régulières, le chiffre peut monter jusqu'à plus de 100. Nous ne devons donc pas protéger les mêmes services qu'il y a 40 ans : les mots de passe ne sont plus secrets au sein d'un groupe restreint mais pour une unique personne.

Les services, voulant bien faire pour éviter les mots de passe trop simples se sont mis en tête qu'il fallait obliger les utilisateurs à en avoir un bon. L'idée c'était d'agrandir l'espace de recherche qu'un attaquant doit parcourir quand il s'attaque aux mots de passe. Pour cela, ils ont demandés à agrandir les alphabets dans lesquels les caractères étaient tirés, ainsi que la taille du mot de passe. Ce qui nous donnait des politiques du genre :

  • votre mot de passe doit contenir une majuscule
  • votre mot de passe doit contenir une minuscule
  • votre mot de passe doit contenir un chiffre
  • votre mot de passe doit contenir un caractère spécial
  • votre mot de passe doit être composé de plus de 8 caractères
  • votre mot de passe ne peut pas contenir les caractères '"-_)&@^ø¨%!:
  • votre mot de passe doit contenir un message inspirant, un sort, un signe de gang, un hiéroglyphe et le sang d'une vierge (source)

Même si dans les débuts ces métriques, qui sont heuristiques, pouvaient être efficaces, on s'est rapidement rendu compte que les utilisateurs avaient tendance à compléter de manière quasiment prédictible leurs mots de passe : majuscule au début, chiffre et caractère spéciaux à la fin. Le cerveau humain, peut-être inconsciemment, essaie de se rapprocher de ce qu'il connaît, en l'occurrence la langue natale de la personne. Ce qui explique que les majuscules soient au début. Les chiffres sont à la fin parce qu'ils ne font pas partie du mot de passe à la base, ils sont 'ajoutés' par la suite, et c'est plus simple de les mettre à la fin. Pareil pour les symboles.

Le comble, même si nous sommes déjà loin dans l'absurdité, c'est qu'aucun site web n'a la même politique ! La preuve dans ce papier de la conférence USENIX (conférence sur la sécurité informatique très reconnue dans le milieu académique). Donc même si nous voulions réutiliser notre mot de passe (à défaut des problèmes engendrés), nous ne pourrions pas ! Cela nous oblige donc à construire des mots de passe plus simple, et simplement rajouter les caractères nécessaires pour satisfaire les conditions de chaque site. On a donc poussé les utilisateurs à affaiblir leur mots de passe en voulant les renforcer !

Ce qu'il faut savoir, c'est que ces politiques de création de mot de passe donnent un avantage à l'attaquant : s'il sait que la politique oblige une majuscule, un chiffre et un symbole, pourquoi essayer le mot de passe azerty ? Plutôt essayer Azerty1!, etc. La politique constitue un filtre pour l'attaquant, et il se trouve que la majorité des utilisateurs mettent la majuscule au début, les chiffres et les symboles spéciaux à la fin ! Encore un biais qui avantage les attaquants !

Aujourd'hui, à cause des fuites de base de données de plus en plus courantes, il faut aussi se prémunir des attaques hors-ligne : l'attaquant a en sa possession une ou plusieurs listes de mots de passe, souvent (mal) hachés, récupérées en piratant le site web en question. Puisque hachés, les mots de passe ne sont pas directement exploitables, l'attaquant va donc essayer un par un des mots de passe candidats et comparer leurs hachés avec la base de donné. 2 hachés identiques signifient que le mot de passe est trouvé (les trolls de la crypto qui me diront COLLISION GNA GNA GNA, je les mets au défi de me générer une seconde pré-image sur SHA1 qui est aussi de l'ASCII voire UTF-8). Et malheureusement, puisque nous sommes humains, la plupart d'entre nous réutilisons nos mots de passe ce qui signifie que l'attaquant pourra se servir du mot de passe trouvé pour s'introduire sur un autre de nos comptes.

Les défenses

C'est bien beau de faire flipper tout le monde, mais maintenant il faut les rassurer. Il faut d'abord que vous sachiez qu'on augmente pas la sécurité sans compromis.

Si vous êtes utilisateur


Selon moi, le meilleur compromis sécurité/utilisabilité est d'utiliser un gestionnaire de mots de passe. C'est un logiciel qui va contenir l'ensemble de vos mots de passe, et qui va en plus vous permettre de les générer. Il en existe une bonne pelle, dont Keepass, LastPass, Dashlane, 1Password, ... Certains sont payants, certains gratuits, certains synchronise automatiquement vos mots de passe, d'autres non ... Y'en a pour tous les goûts, c'est selon. Le gestionnaire vous demandera un master password : c'est le mot de passe principal qui servira à déverrouiller votre coffre-fort.

Les avantages :

  • plus qu'un mot de passe à se souvenir
  • tous les mots de passe sont différents
  • tous les mots de passe sont générés aléatoirement (donc difficile à attaquer)
  • on peut stocker autre chose que des mots de passe, comme la question secrète
  • certains gestionnaire propose de taper automatiquement vos mots de passe sur les sites pré-enregistrés (pas besoin de le recopier bêtement ou de faire copier-coller)
  • dans une certaine mesure, ils protègent du phishing car ne proposent d'entrer le mot de passe que sur le nom de domaine précis (ce que parfois l’œil humain a du mal à repérer)
  • l'attaquant a besoin de votre mot de passe maître ET du fichier contenant l'ensemble des mots de passe, ce qui est plus difficile à obtenir

Inconvénients :

  • un sésame (le master password) dévoile tous vos mots de passe
  • cela demande quelques cliques en plus pour entrer son mot de passe
  • pour certains gestionnaires de mots de passe, c'est moins portable (l'utilisation sur téléphone n'est pas toujours très ergonomique)

Évitez d'utiliser les gestionnaires de mots de passe des navigateurs. Même si c'est chiffré avec le mot de passe maître, Firefox par exemple les déchiffre avant de les synchroniser avec FirefoxSync (ce qui fait qu'ils sont en clair sur les serveurs de Mozilla).

C'est bien tout ça, mais nous venons uniquement de reporter le problème : comment choisir le mot de passe du gestionnaire ? Ce que je conseille, c'est :

  • la méthode XKCD : choisir 4 ou 5 mots de façon aléatoire dans un grand dictionnaire (si en plus vous mélangez les langues, c'est meilleur !)
  • ou la méthode ANSSI : choisir une bonne dizaine de mots, n'ayant aucun sens entre eux, et prendre leurs premières lettres, ce qui donne un mot de passe à au moins 10 caractères. Mettez des majuscules où bon vous semble, des chiffres et des symboles si vous voulez. L'importance d'avoir des mots qui n'ont pas de sens entre eux est grande, puisque sinon c'est attaquable avec les probabilités (chaînes de Markov d'ordre 0).

J'aurai tendance à dire que plus c'est long plus c'est bon, et qu'il vaut mieux avoir un mot de passe de plus de 15 caractère avec que des minuscules et quelques majuscules plutôt qu'un mot de passe de 10 caractères avec minuscules majuscules chiffres et symboles.

Si vous êtes développeur :


Hachez les mots de passe avec du bcrypt. C'est une fonction de hachage spécialement conçue pour stocker des mots de passe. Elle embarque un sel intégré, ce qui vous évite d'avoir à gérer le sel, mais le coût de la fonction est aussi paramétrable, c'est à dire que vous allez pouvoir lui dire combien d'itération vous souhaitez effectuer pour hacher un mot de passe. Par exemple, pour un coût de 10 (ce qui est actuellement recommandé), bcrypt passera votre mot de passe dans Blowfish 2^10 fois.

bcrypt est faite pour ne pas coûter trop cher quand on hache un seul mot de passe, mais devient ultra-coûteuse lorsque l'on souhaite hacher beaucoup de mots de passe (ce qui se passe lors des attaques hors-ligne). Ainsi, les calculs sur cartes graphiques deviennent très lents, quasiment aussi lents que sur processeur.

Ajoutez un pepper, c'est encore mieux. Le pepper a la même vocation que le sel : c'est une chaîne aléatoire, assez longue (prévoir 15 caractères) mais qui ne doit pas être stockée au même endroit que le mot de passe. Simplement parce que dans la plupart des intrusions, seule la base de données est récupérée (injection SQL typique), mais rien d'autre. Stockez donc ce pepper soit dans le code source du site, soit dans un fichier à part. Par exemple, Tumblr a subit une fuite de donnée mais un pepper est présent, ce qui fait qu'à ce jour aucun mot de passe n'a été cassé.

Mettez de l'authentification forte. Voir le draft du NIST à ce sujet.

Si vous êtes RSSI :


C'est peut-être la position la plus délicate, puisque vous êtes entre l'utilisateur et le développeur. Chaque partie va avancer à sa vitesse, il va falloir donc faire preuve de patience et les sensibiliser.

Un exemple qui se présente est le suivant :

  • vous gérez un annuaire LDAP dans lequel se trouve tous vos utilisateurs
  • tous les services utilisés ne sont pas forcément tous développés avec des librairies récentes, et donc tous n'embarquent pas de bcrypt. Pire, chacun a sa manière de hacher les mots de passe qui n'est pas commune aux autres services
  • vous vous retrouvez donc dans votre LDAP avec autant de hachés de vos mots de passe qu'il n'y a des service différent (quasiment)

Donc si demain vous dîtes "Stop, on fait que du bcrypt", ben y'a plein de services qui vont être cassés.

Je dirai donc : n'embêtez pas trop vos utilisateur avec les mots de passe. Minimum 8/10 caractères obligatoires devraient suffire. Avec éventuellement mise en place d'une métrique récente et pertinente selon moi zxcvbn. Aussi, ne forcez pas vos utilisateur à renouveller leurs mots de passe, cela renforce encore le fait de créer des mots de passe faibles et prédictibles : 'totoJanvier', 'totoFévrier', 'totoMars', ...

Conclusion

Évidement tout ça reste une opinion personnelle, c'est mon point de vue en tant que doctorant qui travaille sur le sujet. Il est clair que nous avons besoin de faire de gros efforts de tous les côtés, mais soyons optimistes. Le taux d'acceptation des gestionnaires de mots de passe est en hausse, les services en ligne commencent à prendre des mesures pour mieux sécuriser les données utilisateur.

À vous de faire progresser les mentalités en sensibilisant les personnes autour de vous sur ces problématiques, au moins de faire prendre conscience qu'il y a des solutions, certes jeunes mais fiables comparées à notre cerveau !

Merci à @Hydraze pour son aide !