Les calculatrices en ligne basent leurs résultats sur un ensemble particulier d'hypothèses, qui pourraient ne pas s'appliquer dans un cas particulier. Il n'y a aucune base pour faire confiance aux calculatrices pour fournir des informations sur la façon dont un attaquant pourrait choisir de casser le mot de passe.

Par exemple, si je sais que vous utilisez un modèle, et quel est ce modèle, alors je ajusterait mon bruteforcing pour s'aligner avec le modèle. Il n'y a aucun moyen pour un calculateur en ligne de rendre compte de cela. Il y a d'autres facteurs similaires à prendre en compte. "Entropy" consiste à assurer autant d'aléatoire que possible. Un modèle d'ensemble a un caractère aléatoire très réduit, quels que soient les caractères utilisés.

Donc, oui, interdisez ces modèles évidents, si cela répond à votre objectif.

Je suis cependant préoccupé par votre méthode d'interdiction de ces mots de passe. Vous menez peut-être la mauvaise bataille.

Juste par curiosité, j'ai vérifié cela sur un site Web très connu (sur sa page de connexion) et il a déclaré que cela prendrait des siècles pour se briser.

Ces sites Web ne peut pas être considéré comme un évangile. Beaucoup sont sans valeur et même pour les bons, les résultats doivent être soigneusement interprétés. Tout d'abord, en règle générale, un vérificateur de force peut vous dire de manière concluante qu'un mot de passe est faible mais ne peut pas vraiment vous prouver qu'un mot de passe est fort - le mot de passe dans lequel il ne peut pas trouver de faute pourrait bien tomber dans une attaque qui le compteur ne modélise pas. Pour quelques exemples extrêmes, cet article Ars Technica décrit des attaques par cracking réussies sur des phrases de passe autrement impressionnantes:

Presque immédiatement, un flot de des mots de passe autrefois têtus se sont révélés. Ils comprenaient: "Vais-je jamais revoir votre visage?" (36 caractères), "au commencement était le mot" (29 caractères), "de la genèse aux révélations" (26), "je ne me souviens de rien" (24), "il n'y a pas de chose mais ce qui se réveille" (26), "givemelibertyorgivemedeath" (26 ), et "à l'est du soleil-ouest de la lune" (25).

L'autre chose est que ce n'est pas parce qu'un mètre vous a dit qu'il juge le mot de passe fort que tous ces compteurs le font. Par exemple, le vérificateur zxcvbn, qui est l'un des meilleurs, pense qu'il est cassable en 3 heures par une attaque hors ligne si le hachage du mot de passe est faible:

  password : 23 ## 24 $$ 25 %% 26guesses_log10: 14score: 4 / 4fonction exécution (ms): 3 temps de devinettes: 100 / heure: siècles (attaque en ligne étranglée) 10 / seconde: siècles (attaque en ligne sans limitation) 10k / seconde: siècles ( attaque hors ligne, hachage lent, nombreux cœurs) 10B / seconde: 3 heures (attaque hors ligne, hachage rapide, nombreux cœurs) séquence de correspondance: '23 ## 24 $$ 25 %% 26'pattern: bruteforceguesses_log10: 14   pré>
 Il estime 2 minutes pour  1! 2 @ 3 # 4 $ 5% 6 ^ ,  2 @ 3 # 4 $ 5% 6 ^ 7&  et  a! b @ c # d $ e% f ^  avec une attaque de 10B / seconde (3 ans à 10k / seconde), donc celles qu'il pense sont encore pires. (Bien qu'il les note tous 4/4. Le compteur vous recommande d'accepter réellement l'un de ces mots de passe, car il estime qu'ils sont raisonnablement susceptibles de résister aux attaques  si votre application a implémenté un hachage lent des mots de passe . Mais son analyse prouve en fait qu'ils sont faibles face à une attaque spécifique que vous devriez atténuer.) 
 
 Notez que zxcvbn modélise les attaques en se basant uniquement sur une connaissance générale de la façon dont la plupart des utilisateurs choisissent les mots de passe - il n'a pas toute connaissance spécifique de la manière dont les politiques ou pratiques de mot de passe de votre organisation peuvent permettre une attaque spécialisée contre quelqu'un qui les apprend. Et rappelez-vous toujours que l'outil peut vous dire qu'un mot de passe est faible, mais pas qu'il est fort - zxcvbn estime que des siècles sont nécessaires pour déchiffrer  Est-ce que je reverrai jamais votre visage? , lequel de  L'article d'Ars  que nous savons a en fait été craqué dans la vraie vie. 
 
 
 Maintenant, je suis confus avec la liste, devrais-je marquer ces types de mots de passe comme vulnérables et interdire aux utilisateurs de partir pour eux, même s'ils mettent beaucoup de temps à se briser? 
 
 
 Votre instinct de bannir ces mots de passe s'avère en fait justifié, comme le montrent les résultats de zxcvbn. Le problème est qu'il est peu probable que vous réussissiez à compiler une liste finie de mots de passe qui sont également vulnérables, ni de modèles qu'un attaquant pourrait exploiter avec succès. Par exemple, pour attraper tous les mots de passe que zxcvbn pense être aussi vulnérables que les trois derniers, vous auriez besoin d'une liste de 1,2 billion d'entrées (10 milliards de mots de passe / seconde × 2 minutes). Pas pratique. Même si vous essayez de condenser les choses en une petite liste de modèles à rejeter, je ne compterais pas pour réussir à déjouer vos attaquants. 
 Une chose que vous devez absolument faire est d'utiliser un hachage de mot de passe fort, avec les fonctions de hachage de mot de passe bcrypt ou Argon2. C'est ce que les résultats de zxcvbn ci-dessus appellent "hachage lent" et cela rend probablement vos entrées de mot de passe beaucoup plus difficiles à casser. (Mais encore une fois, rappelez-vous qu'un vérificateur de force peut vous dire que certains mots de passe sont certainement dangereux, mais pas qu'ils sont sûrs.) 
 
 Ce que vous devez également considérer: 
 

• une petite liste (des milliers) de mots de passe connus pour être très courants, et interdisez-les. Ces listes peuvent être facilement trouvées en ligne.
• Utilisez la liste de 500 millions de mots de passe violés de Troy Hunt, qui dispose également d'une API en ligne. (Assurez-vous de lire le matériel sur le k-anonymat afin de ne pas envoyer de mots de passe à l'API!)
• Utilisez une bibliothèque de compteurs intelligents comme zxcvbn, qui est un une alternative bien plus sophistiquée à la détection de modèles comme celle que vous envisagez.
• Mettez en œuvre un deuxième facteur d'authentification, de sorte que les mots de passe ne soient pas votre seule ligne de défense.

La devinabilité des mots de passe signifie savoir quelque chose sur le type de mots de passe que les gens peuvent choisir. Nous savons tous que "Password" est devinable car c'est un mot anglais. Mais sachez que vous devez soit connaître l'anglais, soit avoir une idée de la façon dont l'anglais ou d'autres langues apparentées épellent les mots. Un étranger de quelque part dans les environs de Bételgeuse qui n'a jamais été exposé à l'anglais ou à une autre langue humaine ne saura pas que "Password" est facilement devinable. En d'autres termes, les modèles sont quelque peu subjectifs, ce qui (au-delà d'un certain niveau) les rend terriblement difficiles à prédire à l'avance.

De même, pour certains des mots de passe de votre liste, il n'est pas immédiatement évident de savoir ce que modèle est. 1! 2 @ 3 # 4 $ 5% 6 ^ semble quelque peu "aléatoire" à première vue, mais vous remarquerez rapidement que sur un clavier QWERTY, c'est simplement 1-6, et en alternant tous les autres caractères avec la touche Maj.

De plus, si quelqu'un vous montrait le mot de passe CPE1704TKS, vous pourriez aussi penser que c'est un bon mot de passe. Il a 10 caractères de lettres et de chiffres, il n'y a pas de motif répétable déterminable, et ce n'est pas un mot dans aucune langue humaine. Vous vous trompez cependant, et ce n'est pas un bon mot de passe car c'est le mot de passe utilisé pour lancer les missiles nucléaires à la fin du film Wargames.

Pour cette raison, en utilisant des calculs de "crackability" (basé sur la longueur et la sélection de caractères) à partir d'un site Web aléatoire sont en grande partie faux. De plus, ils dépendent de l'obtention des hachages de mots de passe par quelqu'un, ce qui constitue en soi un compromis de sécurité majeur. Ils sont doublement faux car ils impliquent que vous savez à quelle vitesse un hachage prend. Les vitesses de hachage varient de plusieurs ordres de grandeur en fonction de l'algorithme que vous avez choisi. Prenez donc les scores de "crackability" avec un grain de sel. La plupart des attaques contre les mots de passe de nos jours utilisent des mots de passe courants ou des mots de passe réutilisés et non des hachages de mots de passe volés.

En réalité, cela revient simplement à maintenir une liste de "mauvais mots de passe" que d'autres personnes ont trouvés au fil des ans et qui ont une sorte de signification particulière. Je suppose que c'est de là que viennent les responsables de la sécurité.

Il est impossible de prouver qu'un mot de passe donné est difficile à déchiffrer.

Ce que vous entendez par l'affirmation (correcte) selon laquelle ces mots sont "hautement vulnérables", c'est que là Il existe un algorithme plus facile à deviner pour les générer, à savoir "frapper la ligne numérique d'un clavier QWERTY dans tel ou tel motif simple". Il s'agit d'un algorithme facile à reconnaître pour un humain qui passe toute la journée à presser ses doigts sur un tel clavier, mais les motifs sur un tel clavier sont en fait plutôt «non évidents pour un ordinateur», car en fait, la plupart des programmes informatiques ne Je ne me soucie pas du tout de la disposition physique des touches ^† .

Je pourrais également donner un exemple comme YWJjZGVmZ2hpamts , que vous pourriez penser un mot de passe raisonnablement sûr, mais vous auriez tort, car il se trouve qu'il s'agit du codage Base64 de la chaîne abcdefghijkl , et cela peut sembler totalement évident à une IA pour laquelle un string est avant tout un modèle de bits.

La notion de la façon dont un bit d'information donné peut être exprimé est appelée complexité de Kolmogorov. Malgré la définition simple, c'est en fait un concept très délicat: cela dépend fortement de la langue dans laquelle vous voulez tout exprimer, et il est incomputable . Vraiment, le mieux que vous puissiez faire est d'évaluer tous les programmes courts possibles dans un langage de programmation expressif avec une grande bibliothèque standard, mais si cela ne réussit pas ^‡ cela ne garantit en aucun cas qu'il n'y a pas de bas. entropie moyen de calculer le mot de passe dans une autre langue qui comprend une fonction standard cruciale. Si vous ne connaissez pas la disposition QWERTY, vous pourriez également penser que asdfqwerzxcv est sûr, malgré l'évidence totale lorsque vous le connaissez.

Le résultat: si vous trouvez une représentation à faible entropie d'un mot de passe donné, alors oui, interdisez-la. Mais ne prenez jamais l'assertion de qui que ce soit (y compris de tout programme ) pour valeur nominale qu'un mot de passe donné est sécurisé s'il ne sait pas comment le mot de passe a été réellement généré. Si vous voulez garantir des mots de passe vraiment incassables, le seul moyen est de vous assurer qu'ils proviennent d'un processus aléatoire physique quantique.

^† _{Tout programme concerné par le craquage de mots de passe devrait cependant connaître les dispositions de clavier, car il est bien connu que les humains ont tendance à recourir à de tels modèles. De plus, 23 ## 24 $$ 25 %% 26 est assez facile même sans connaître la disposition du clavier, car la ligne numérique est presque ordonnée en ASCII. Donc, ces sites Web font vraiment un travail terrible ici.}

^‡ _{C'est même sans tenir compte des problèmes d'exécution. Ce que vous faites ici est tout aussi difficile que de forcer brutalement un mot de passe inconnu .}

Un mot de passe comme "12345678" peut être considéré comme aléatoire, si vous le souhaitez. Si vous utilisez un générateur de mots de passe aléatoires, la probabilité de générer "12345678" est la même que celle de "4h2Ud8yG" (en ne considérant que les mots de passe alphanumériques). Et "12345678" peut être aussi difficile à casser que "4h2Ud8yG", si vous le forcez de manière brutale dans la plage de "00000000" à "ZZZZZZZZ". Mais la vérité est que les mots de passe ne doivent pas être simplement aléatoires, ils doivent également paraître aléatoires. Pourquoi? Étant donné que les attaquants utilisent souvent la force brute basée sur des dictionnaires ou des modèles, les mots de passe qui ne sont pas basés sur des mots ou des modèles sont plus sécurisés. De plus, si des mots et des modèles sont utilisés pour faciliter la mémorisation du mot de passe, il est probable que tous les autres mots de passe utilisés par la même personne seront plus faciles à retenir de la même manière. Donc, si un attaquant vole l'un de vos mots de passe et qu'il ressemble à "John75", il est susceptible de briser la majorité de vos mots de passe par des modèles de force brute tels que "nom + numéro", "mot + numéro" ou certaines variantes. Mais si l'attaquant vole l'un de vos mots de passe et qu'il ressemble au hasard "4h2Ud8yG", alors il ne pourra en extraire aucune information.

Vous avez donc raison lorsque vous dites ces mots de passe que vous avez ne sont pas vraiment sécurisés. Ils n'ont même pas toute l'entropie que vous pensez avoir! Et c'est parce que l'entropie de mot de passe est basée sur la façon dont un mot de passe ressemble, ou la façon dont un mot de passe est créé. Un mot de passe comme "1! 2 @ 3 # 4 $ 5% 6 ^", si vous le pensez comme "nombre suivi du symbole, six fois", vous auriez (10x10) ^ 6 = 10 ^ 12 possibilités. Ce qui est inférieur aux possibilités pour un simple mot de passe de 8 caractères composé de lettres minuscules et de chiffres: 36 ^ 8 = 2,8 x 10 ^ 12 possibilités. Mais si vous pensez à cet exemple de mot de passe comme "nombre suivi du symbole sur la même touche, à partir de 1 dans l'ordre croissant, six fois ", alors les possibilités totales sont ... une seule!

Tout d'abord, ces indicateurs de sévérité des mots de passe sont des directives, pas une vérité absolue.

Deuxièmement, le degré de sécurité d'un mot de passe ou le temps qu'il faudrait pour déchiffrer dépend de quelques facteurs. Pour mieux comprendre cela, il est important de comprendre comment les mots de passe «se cassent» en premier lieu.

Il existe 3 attaques courantes contre les mots de passe:

1. Les attaquants essaient de se connecter à un service en devinant le mot de passe
2. Les attaquants ont trouvé la même combinaison nom d'utilisateur / mot de passe dans une violation distincte et l'utilisent maintenant contre un service non violé (bourrage d'informations d'identification)
3. Les attaquants ont obtenu la base de données vidage d'un service et avoir le hachage du mot de passe. Ils forcent maintenant brutalement les hachages pour déterminer le mot de passe en clair.

Pour empêcher les attaquants de deviner directement les mots de passe, nous appliquons une sorte de «règle d'entropie» AND nous limitons les tentatives de connexion. De cette façon, les attaquants ne peuvent pas forcer directement votre service.

Pour empêcher le bourrage d'informations d'identification est une tâche plus difficile. Quelle que soit la force avec laquelle vous forcez les mots de passe, cela ne sera d'aucune utilité si l'utilisateur avait le même mot de passe sur un système piraté distinct - et ce système l'a stocké en texte clair!

Certaines entreprises (notamment Amazon, LinkedIn et OpenTable) accèdent même à des violations de données et alertent leurs clients - même si ces violations sont en dehors desdites entreprises. Cela aide à se protéger contre le bourrage d'informations d'identification (un peu!), Mais cela pourrait être un peu trop loin.

Enfin, il y a le forçage brutal typique d'un hachage de mot de passe. C'est là qu'un attaquant a en quelque sorte mis la main sur les hachages de mot de passe des utilisateurs et essaie maintenant de deviner le texte en clair à partir des hachages. Voici où nous entendons couramment le trope il faudra des siècles pour rompre .

En général, l'attaquant utilisera un outil comme ocl-hashcat en combinaison avec une liste de mots de mots de passe communs (comme les mots de passe RockYou ou Top1000, etc.) pour deviner le texte en clair. Les attaquants peuvent également forcer brutalement chaque combinaison de lettres, de chiffres et de caractères spéciaux, mais ce n'est pas courant, car c'est moins efficace qu'une liste de mots.

Le ralentissement de l'attaque, nous nous appuyons généralement sur:

• Utilisation d'une fonction de hachage Strong (Bcrypt au lieu de MD5)
• Salage des mots de passe individuels ( pour forcer les attaquants à la force brute un par un)
• Empêcher les utilisateurs d'utiliser des mots de passe faibles
• Empêcher les utilisateurs d'utiliser des mots de passe lors de violations de données précédentes (car la liste de mots est composée de mots de passe précédemment violés) .

Pour les 2 derniers, NIST recommande ce qui suit:

Lors du traitement des demandes d'établissement et de modification de secrets mémorisés, les vérificateurs DOIVENT comparer les secrets potentiels par rapport à une liste contenant des valeurs connues pour être couramment utilisées, attendues ou compromises. Par exemple, la liste PEUT inclure, mais sans s'y limiter:

• Mots de passe obtenus à partir de corpus de violation précédents.
• Mots du dictionnaire.
• Répétitif ou caractères séquentiels (par exemple «aaaaaa», «1234abcd»).
• Mots spécifiques au contexte, tels que le nom du service, le nom d'utilisateur et ses dérivés.

De toute évidence, les services doivent forcer la réinitialisation du mot de passe une fois qu'une faille est découverte sur leur service.

En bref, ne soyez pas confus sur le fait de prendre des siècles pour casser des bêtises. Appliquez un ensemble raisonnable de pratiques autour de la protection des mots de passe et vous devriez être bon, ne vous fiez pas entièrement à ces indicateurs de force de mot de passe pour déterminer votre posture de sécurité. Ce lien NIST est un bon point de départ.

La plupart des conseils en ligne sur les mots de passe sont, pour le dire amical, sans aucune base solide. Cela vaut particulièrement pour la soi-disant complexité des mots de passe, qui est basée sur un mythe des années 80 et heureusement - après que l'auteur original du NIST l'ait admis l'année dernière - en voie de disparition.

Vous pouvez pas faire une estimation de la force du mot de passe sans comprendre ce que sont réellement vos menaces. Toutes les calculatrices en ligne triviales sont absurdes car elles ne font que faire des calculs sans tenir compte de ce que vous essayez de protéger contre^.

Votre menace pourrait être brutale fort>. Dans ce cas, la première chose à faire est de ne pas autoriser les attaques par force brute. Si quelqu'un entre un mauvais mot de passe cent fois et que vous ne le verrouillez pas, vous faites quelque chose de mal qui n'a rien à voir avec la force du mot de passe. La deuxième chose à faire est longueur> complexité (mettre que dans Google, excellent article).

Si votre menace est une attaque par dictionnaire sur vos hachages de mot de passe, la première chose à faire est de protéger correctement vos hachages. La seconde est de saler et de hacher correctement avec une fonction de hachage appropriée (bcrypt, scrypt, etc. - pas MD5 ou SHA1). Le troisième est de ne pas autoriser les mots simples du dictionnaire et les permutations. Utilisez la même logique que les crackers, certains d'entre eux sont accessibles au public.

Si votre menace est de surfer sur l'épaule ou des autocollants post-it, vous voulez éviter la complexité absurde et assurez-vous que vos utilisateurs peuvent réellement se souvenir de leurs mots de passe et saisissez-les rapidement. Encore une fois, longueur> complexité. Faites une longueur minimale de 12 caractères, mais autorisez les mots composés.

Et ainsi de suite ...

En bref: tenez compte de vos menaces, ne vous fiez pas aux estimations mathématiques triviales.

Juste par curiosité, j'ai vérifié cela sur un site Web très connu (sur sa page de connexion), et il a déclaré que cela prendrait des siècles pour se rompre.

Tel les affirmations sont toujours très douteuses.

Le problème fondamental est que pour calculer combien de temps il faudrait à un attaquant pour casser un mot de passe, vous avez besoin d'un modèle de l'attaquant.

Un attaquant idéalisé le ferait. essayez les mots de passe dans l'ordre du plus probable au moins probable. Bien sûr, un véritable attaquant ne sait pas quelle est la probabilité d'un mot de passe donné, il doit donc deviner, il combinera généralement une sorte de dictionnaire (qui, si l'attaquant est un peu compétitif, contiendra beaucoup plus que de simples mots anglais) avec un un tas de règles de génération.

Le problème est que les modèles d'attaquants utilisés par les compteurs de force de mot de passe sont souvent loin derrière les attaquants réels dans la taille de leurs dictionnaires et la complexité de leurs règles.

Le problème fondamental avec les restrictions de mot de passe est que, quelle que soit la restriction que vous faites, les utilisateurs feront souvent le strict minimum pour que leur mot de passe passe.

Maintenant, cela peut ajouter de l'entropie, il y a normalement plus d'un moyen minimum de muter un mot de passe afin qu'il passe les règles, mais l'entropie ajoutée est beaucoup plus petite qu'une analyse naïve peut le suggérer. Par exemple, si vous forcez les utilisateurs à ajouter un nombre à leur mot de passe, un nombre disproportionné d'entre eux choisiront probablement 1.

Vous êtes probablement confus en supposant qu'il est possible de définir la vulnérabilité des mots de passe a priori. Au lieu de cela, cela dépend fortement du modèle qu'un attaquant réel essaiera en premier. Un attaquant opportuniste essaierait probablement d'abord un dictionnaire ou des listes de mots de passe divulgués. Mais en faisant un effort même modéré, ils peuvent devenir assez précis. C'est une des raisons pour lesquelles l'application des directives sur les mots de passe est une bataille perdue. La plupart des directives encouragent les utilisateurs à respecter certaines exigences minimales lors du choix de leurs mots de passe. Cela peut aider à les forcer brutalement . Par exemple,

• une longueur de mot de passe minimale de X caractères permet à un attaquant d'éviter d'essayer tous les mots de passe plus courts que X et de se concentrer sur les mots de passe de longueur X, X + 1 ou X +2 en supposant que de nombreux utilisateurs ne remplissent que la longueur minimale requise.

• En appliquant un modèle tel que «minuscules, majuscules, nombres et caractères spéciaux», un attaquant peut supposer qu'il y a les utilisateurs qui dérivent leur mot de passe en utilisant exactement ce modèle .

• Il serait possible de leur dire si leur mot de passe était un mot de passe divulgué, mais là est le risque qu'ils finiraient par le modifier jusqu'à ce qu'il passe. Encore une fois, c'est un indice pour les attaquants sur la façon de diriger leur forçage brutal.

• La longueur maximale est assez évidente. Dans le meilleur des cas, une longueur réduit l'avantage d'utiliser des gestionnaires de mots de passe. Dans le pire des cas, ils peuvent faire allusion aux limites technologiques sous-jacentes du système de connexion. En outre, ils placent une limite supérieure sur l'effort le plus défavorable qu'un attaquant doit déployer.

Pour déterminer la difficulté à déchiffrer un mot de passe, vous devez connaître son entropie, ce que ces sites ne peuvent évidemment pas connaître. Ils font leur meilleure supposition et retournent ensuite cela comme résultat.

Afin de calculer correctement l'entropie d'un mot de passe, vous devez supposer que l'attaquant en sait autant que le créateur sur la façon dont le mot de passe a été créé. Si le créateur inclut toujours l'un des deux mots de 10 lettres, l'attaquant doit savoir à la fois qu'un de ces mots sera présent et ce qu'il est.

De là, vous pouvez voir que votre modèle est très faible entropie (pas plus de 7 bits). Mais comme les sites Web ne le savent pas, ils le notent beaucoup plus. Si vous voulez un bon mot de passe, vous devez avoir un caractère aléatoire. Comment amener un utilisateur à accepter et à inclure le caractère aléatoire dans le mot de passe est un problème. Mieux vaut essayer de trouver comment amener quelqu'un d'autre à faire le mot de passe ou l'équivalent du mot de passe.