Votre fichu mot de passe est bien trop court

Cet article est une traduction du très bon article de Jeff Atwood : http://blog.codinghorror.com/your-password-is-too-damn-short/ La problématique du mot de passe se pose pour les utilisateurs, mais aussi pour les développeurs. Jeff analyse dans son article quelle longueur de mot de passe utiliser et quelles sont les bonnes pratiques pour les développeurs.

« Je suis un peu fatigué d’écrire à propos des mots de passe. Mais comme les impôts, les emails et les conjonctivites, ce n’est pas près de disparaître. Voilà ce que je sais et qui a été prouvé par de nombreuses expériences :

• Quoi que vous leur disiez, les utilisateurs choisiront toujours des mots de passe simples.
• Quoi que vous leur disiez, les utilisateurs utiliseront le même mot de passe encore et encore sur plusieurs appareils, applications et sites web. Si vous êtes chanceux, ils utiliseront deux mots de passe au lieu d’un.

Que pouvons nous faire en tant que développeurs ?

• Arrêter de demander des mots de passe, et laisser les gens se connecter avec Google, Facebook, Twitter, Yahoo, ou tout autre forme de « Permis de Conduire Internet » que vous pouvez supporter. Les meilleurs mots de passe sont ceux que vous ne stockez pas.
• Pousser les navigateurs à supporter automatiquement la génération/gestion de mots de passe. Idéalement supporté par le système d’exploitation lui-même, mais cela requiert un stockage dans le Cloud et que tout le monde ait le même, ce qui semble moins probable que pour un nvaigateur. Chrome, au moins, agit dans cette direction.
• Les utilisateurs bêtes, au moment de s’enregistrer, quand ils entrent des mots de passe qui sont …
  • Trop courts : UY7dFd
  • Sans assez d’entropie : aaaaaaaaa
  • Semblables à des mots du Dictionnaire : mangeursdefourmis1

Bien souvent, l’enregistrement du mot de passe est accompagné d’un calculateur de résistance, qui propose un retour en même temps que vous tapez.

Si vous ne pouvez pas éviter de stocker le mot de passe – les deux premières solutions citées plus haut dispensent l’utilisateur de choisir un nouveau mot de passe – alors montrer une estimation de la force du mot de passe est une bonne chose si l’utilisateur y met du sien.

La meilleure façon de construire un mot de passe sûr est de le faire long. En admettant que le reste importe peu, la loi de croissance exponentielle signifie qu’un mot de passe plus long est un meilleur mot de passe. C’est pourquoi j’ai toujours été fan des « passphrases » (mot de passe sous forme de phrase), bien qu’elles soient très pénibles à saisir via un écran tactile dans notre nouveau monde mobile – et c’est un problème grandissant.
Mais à quel moment court est trop court ?

Quand nous avons créé Discourse, je devais choisir une taille de mot de passe minimale que nous pourrions accepter. J’ai choisi une taille de 8, basée sur ce que je connaissais des mes recherches sur le hashage rapide. Un mot de passe de 8 caractères n’est pas génial, mais si vous utilisez une bonne variété de caractères, cela devrait être suffisamment résistant face à une attaque.

Par attaque, je ne parle pas d’une attaque automatisée contre un site ou une application en testant plusieurs mots de passe. Cela existe, pour des mots de passe vraiment communs, mais c’est une attaque quasiment impatricable sur la plupart des sites, car ils disposent d’un nombre de tentatives limité dans le temps.

Ce que je veux dire par attaque est une attaque hors-ligne sur les hashs de votre mot de passe, où un attaquant obtient l’accès à la base de données utilisateurs. Ce type de fuite arrive tout le temps. Et cela ne cessera jamais.

Si vous n’avez vraiment pas de chance, le développeur responsable de cette application, service ou site web conserve les mots de passe en clair. Cela n’arrive heureusement pas trop souvent, grâce à des efforts d’éducation. Le progrès ! Mais même si les développeurs stockent proprement une version hashée de votre mot de passe plutôt que le mot de passe lui-même, vous devriez prier pour qu’ils utilisent un algorithme de hash très lent, complexe et gourmand en mémoire, comme bcrypt. Et qu’ils ont choisir un grand nombre d’itérations. Oups, désolé, ceci a été écrit dans les heures sombres de 2010 et est maintenant obsolète. Je voulais dire scrypt. Yeah, script, c’est le bon cheval.

Alors, sommes nous en sécurité ? Vraiment ? Voyons ça.

• Commençons avec un mot de passe de 8 caractères généré aléatoirement. Notez que 8 caractères est aussi la taille par défaut du générateur. J’obtiens U6zruRWL.
• Passez-le dans le testeur de mot de passe du Gibson Research Corporation.
• Regardez le résultat « Massive Cracking Array », qui est 2.2 secondes.
• Allez vous allonger et mettez une serviette chaude sur votre visage.

Vous pouvez lire ça et penser qu’une « attaque massive par cluster » est quelque chose qui est difficile à accomplir. J’ai le regret de vous informer que construire un cluster de, disons 24 cartes graphiques abordables optimisées pour le calcul de hash, est largement à la portée des institutions gouvernementales et de n’importe quelle petite entreprise qui peut se payer 40000€ d’équipements. Et pas besoin d’acheter quand vous pouvez louer – il existe beaucoup de serveurs en ligne équipés de cartes graphiques de ce type de nos jours. Et par dessus tout, imaginez ce qu’une nation motivée pourrait faire. On croit rêver.

Même si vous ne me croyez pas, mais vous devriez, le scénario d’attaque basique hors ligne, beaucoup plus facile à éxecuter, ne prend que 37 minutes.

Peut-etre que vous êtes sceptique. C’est génial, moi aussi. Que se passe-t-il quand nous essayons avec un mot de passe plus long généré par random.org (prenons l’attaque massive par cluster) ?

9 caractères    =>    2 minutes
10 caractères    =>    2 heures
11 caractères    =>    6 jours
12 caractères    =>    1 an
13 caractères    =>    64 ans

Le générateur de random.org utilise « uniquement » des majuscules, minuscules, et nombres. Et si nous ajoutions des caractères spéciaux, pour garder Q*Bert heureux ?

8 caractères    =>    1 minute
9 caractères    =>    2 heures
10 caractères    =>    1 semaine
11 caractères    =>    2 ans
12 caractères    =>    200 ans

C’est un peu mieux, mais vous ne pouvez vous sentir en sécurité qu’au dessus de 12 caractères, même avec un mot de passe composé de majuscules, minuscules, nombres et caractères spéciaux.

C’est malheureusement en admettant que les scénari d’attaque massive par cluster vont disparaître. Bien qu’il y ait une taille de mot de passe où toutes les tentatives de cassage échoueront face à la montage exponentielle insurmontable, ces nombres ne vont aller qu’en empirant dans le temps.

Donc après tout, voici ce que je vous dis, pauvre utilisateur assiégé :

A moins que votre mot de passe fasse au moins 12 caractères, vous êtes vulnérable.

Cela devrait être la taille minimale d’un mot de passe à utiliser pour n’importe quel service. Générez votre mot de passe avec n’importe quel générateur hors-ligne, avec des dés, ou votre propre méthode maison en ajoutant des mots, nombres et caractères ensemble – débrouillez-vous mais assurez-vous que vos mots de passe font tous au moins 12 caractères.

Maintenant, pour être honnête, comme je l’ai mentionné plus tôt, cela dépend énormément de l’algorithme de hashage choisi. Mais vous devez partir du principe que vous utiliserez sera hashé avec le plus faible hash existant. Un qui est facile à calculer pour les cartes graphiques. Il y a beaucoup de vieux logiciels et systèmes dehors, et ce pour encore un long moment.

Et pour les développeurs :

1. Choisissez votre nouvel algorithme de hashage de mot de passe avec attention, et migrez tous les vieux mots de passe vers un hash plus difficile à calculer. Vous devez choisir des hashs spécialement conçus pour résister aux cartes graphiques, comme scrypt.
2. Même si vous choisisser le « bon » hash, vous pouvez être vulnérable si votre « work factor » (nombre d’itérations) n’est pas assez grand. Matsano recommande ce qui suit :
   • scrypt : N=2^14, r=8, p=1
   • bcrypt : cost=11
   • PBKDF2 with SHA256 : iterations=86 000

Mais ce ne sont que des conseils, vous devez adapter le système de hashage à ce qui est disponible et raisonnable sur vos serveurs et appareils. Par exemple, nous avons eu un petit bug dans Discourse où nous autorisions les gens à entrer un mot de passe de 20 000 caractères dans le formulaire, et calculer le hash de ça prenait, euh … quelques secondes.

Maintenant, veuillez m’excuser, j’ai besoin de changer mon mot de passe Paypal. »