Confus d'utiliser un mot de passe qui "mettrait des siècles à se casser"

Question

Je parle de ce mot de passe - 23##24$$25%%26 et les similaires composés de caractères spéciaux apparaissant dans un motif, que les utilisateurs utilisent de nos jours beaucoup.

Au travail (société financière), je créais une liste de mauvais mots de passe que les utilisateurs ne devraient pas être autorisés à choisir, impliquant certains cycles ou modèles, et le type ci-dessus présente ce trait de contenir des nombres consécutifs prenant en sandwich des caractères spéciaux (répété certaines fois, ici deux fois).

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 à briser.

Quelques autres exemples dans la liste qui prendraient des années à se rompre, mais sont très vulnérables:

1!2@3#4$5%6^ 2@3#4$5%6^7& a!b@c#d$e%f^

Maintenant, je suis confus avec la liste, dois-je marquer ces types de mots de passe comme vulnérables et interdire aux utilisateurs de les utiliser, même s'ils mettent beaucoup de temps à se casser?

Remarque 1 - Nous considérons ces personnes vulnérables car de nombreux utilisateurs (et, par conséquent, plusieurs mots de passe similaires) suivent cette tendance pour se souvenir facilement des choses.
Note 2 - Nous sommes confus parce que les gars de la sécurité sont tous sur l'augmentation de l'entropie, ce qu'ils ignorent, c'est un ordre accru de hachages similaires dans la base de données
Il y a eu une friction entre les gars quant à l'endroit où nous tracer une ligne, définissant quel mot de passe doit être autorisé ou interdit.

Modifications:

Ce site Web dont je parle, mais que je ne nommerai pas, sur lequel j'ai testé le mot de passe est à peu près connu de tous les pirates éthiques/contraires à l'éthique, presque tous les utilisateurs ici sur Stack Exchange et de nombreuses grandes/petites entreprises (lorsqu'ils utilisent ses services) .
Nous ne stockons pas les mots de passe en texte brut. Nous utilisons un algorithme de hachage de Nice, pas fait maison.
Un incident nous a amenés à revoir nos politiques de mot de passe et nous avons créé une base de données distincte db-2 sur une machine différente, sur laquelle nous avons stocké le mot de passe de l'utilisateur simply_hashed_newly_created (pas de sel, rien, juste hashed_password) sans stocker les détails who_created, when_created. Nous l'avons fait pour une courte période seulement. Tout changement de mot de passe est également entré dans cette base de données. Alors que, dans notre base de données d'origine db-1 sat secure_salted_passwords.
Nous avons continué à créer une liste L de mots de passe vulnérables hachés également, en suivant un modèle, et nous avons été amusés lorsque nous avons fait correspondre L & db-2 - nous avons vu plusieurs groupes de mots de passe similaires, avec certains modèles. L et db-2 ont ensuite été effacés des systèmes.
db-2 a été conservé sur une machine hautement sécurisée et était sûr, ne dévoilera pas les détails exacts ici. Nous sommes conscients que même les entrefers ou les prises électriques ne sont pas sécurisés. Tous les deux db-2 et L ont été détruits.
Ne vous inquiétez pas des mots de passe publiés ici, car nous avons déjà mené notre petite expérience, et tous ces utilisateurs spécifiques ont été faits pour réinitialiser leurs mots de passe (bien sûr, un nouveau mot de passe différent de l'ancien). C'est la raison pour laquelle je suis venu ici en postant quelques échantillons.
Et, j'ai également commenté ici plus tôt, que j'ai publié un échantillon de mots de passe de la logique du générateur qui a créé une très grande liste de mots de passe hachés, qui peuvent ou non être dans db-2. Encore une fois, puisque tous ces utilisateurs ont un nouveau mot de passe, donc pas de soucis, tout est sûr et sécurisé.
Comme je connais le fonctionnement du générateur, j'ai testé quelques exemples de mots de passe sur un site Web, et nous nous sommes trompés sur ceux à autoriser ou à refuser, sur quels critères.

Merci beaucoup pour vos réponses, acceptez ma gratitude. Sur la base des réponses, pour l'instant, nous avons reporté toute sorte de restriction à mettre sur le choix du mot de passe.

schroeder · Accepted Answer

Les calculateurs en ligne basent leurs résultats sur un ensemble particulier d'hypothèses, celles qui pourraient ne pas s'appliquer dans un seul cas. Il n'y a aucune base pour faire confiance aux calculatrices pour fournir un aperçu de 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, j'ajusterais mon bruteforcing pour l'aligner avec le modèle. Il n'y a aucun moyen pour une calculatrice en ligne de tenir compte de cela. Il y a d'autres facteurs similaires à prendre en compte. L '"entropie" consiste à garantir autant de hasard que possible. Un motif défini a un caractère aléatoire très réduit, quels que soient les caractères utilisés.

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

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

Luis Casillas · Answer

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 à briser.

Ces sites Web ne peuvent pas être considérés comme un évangile. Beaucoup ne valent rien, et même pour les bons, les résultats doivent être interprétés avec soin. 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 défaut pourrait bien tomber sous le coup d'une attaque qui le compteur ne modélise pas. Pour quelques exemples extrêmes, cet article d'Ars Technica décrit des attaques de craquage réussies sur certaines phrases de passe par ailleurs impressionnantes :

Presque immédiatement, un flot de mots de passe autrefois tenaces s'est révélé. Ils incluaient: "Est-ce que je reverrai jamais ton visage?" (36 caractères), "au commencement était la Parole" (29 caractères), "de la genèse aux révélations" (26), "Je ne me souviens de rien" (24), "thereisnofatebutwhatwemake" (26), "givemelibertyorgivemedeath" (26 ) et "à l'est du sud-ouest de la lune" (25).

L'autre chose est que ce n'est pas parce qu'un compteur 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 que cela peut être rompu en 3 heures par une attaque hors ligne si le hachage du mot de passe est faible:

password: 23##24$$25%%26 guesses_log10: 14 score: 4 / 4 function runtime (ms): 3 guess times: 100 / hour: centuries (throttled online attack) 10 / second: centuries (unthrottled online attack) 10k / second: centuries (offline attack, slow hash, many cores) 10B / second: 3 hours (offline attack, fast hash, many cores) match sequence: '23##24$$25%%26' pattern: bruteforce guesses_log10: 14

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 ceux qu'il pense sont encore pires. (Bien qu'il les note tous 4/4. Le compteur recommande que vous acceptiez 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é hachage lent des mots de passe . Mais son analyse prouve en fait qu'ils sont faibles face à une attaque spécifique que vous devez 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 aucune connaissance spécifique sur la façon dont les politiques ou pratiques de votre organisation en matière de mots de passe peuvent permettre une attaque spécialisée à quelqu'un qui les apprend. Et rappelez-vous toujours, l'outil peut vous dire qu'un mot de passe est faible, mais pas qu'il est fort - zxcvbn estime les siècles à craquer Am i ever gonna see your face again?, qui de l'article Ars que nous connaissons a été réellement craqué dans la vie réelle.

Maintenant, je suis confus avec la liste, dois-je marquer ces types de mots de passe comme vulnérables et interdire aux utilisateurs de les utiliser, même s'ils mettent beaucoup de temps à se casser?

Votre instinct que ces mots de passe devraient être interdits s'avère en fait avoir une justification, 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 considère comme aussi vulnérables que les trois derniers, vous auriez besoin d'une liste avec 1,2 billion d'entrées (10B mots de passe/seconde × 2 minutes). Pas pratique. Même si vous essayez de condenser les choses sur une petite liste de modèles à rejeter, je ne compterais pas sur le succès de 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 à briser. (Mais encore une fois, rappelez-vous qu'un vérificateur de force peut vous dire qu'un mot de passe est certainement dangereux, mais pas qu'il est sûr.)

Choses à considérer en plus:

Utilisez une petite liste (des milliers) de mots de passe connus pour être très courants et interdisez-les. Ces listes sont facilement accessibles en ligne.
Utilisez 500M + liste de mots de passe violée de Troy Hunt , qui dispose également d'une API en ligne. (Assurez-vous de lire le matériel sur k-anonymity afin de ne pas réellement envoyer de mots de passe à l'API!)
Utilisez une bibliothèque de mesure de force intelligente comme zxcvbn, qui est une alternative beaucoup plus sophistiquée à la détection de modèle comme ce que vous envisagez.
Implémentez un deuxième facteur d'authentification, afin que les mots de passe ne soient pas votre seule ligne de défense.

Steve Sether · Answer

Deviner les mots de passe signifie savoir quelque chose sur le type de mots de passe que les gens pourraient choisir. Nous savons tous que "mot de passe" est devinable car c'est un mot anglais. Mais pour savoir 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 épelent des 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évoir à l'avance.

De même, pour certains des mots de passe de votre liste, il n'est pas immédiatement évident quel est le modèle. 1! 2 @ 3 # 4 $ 5% 6 ^ semble un 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 autre personnage avec la touche Maj.

De plus, si quelqu'un vous a montré le mot de passe CPE1704TKS, vous pourriez également 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 auriez tort 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, l'utilisation de calculs de "fissurabilité" (basés sur la longueur et la sélection de caractères) à partir d'un site Web aléatoire est largement bidon. De plus, ils dépendent de l'obtention de hachages de mot de passe par quelqu'un, ce qui constitue en soi un compromis majeur en matière de sécurité. 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 selon l'algorithme que vous avez choisi. Prenez donc des scores de "crackabilité" avec un grain de sel. De nos jours, la plupart des attaques contre les mots de passe utilisent des mots de passe courants ou des mots de passe réutilisés et non des hachages de mots de passe volés.

Vraiment, 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 signification particulière. Je suppose que c'est de là que viennent les gars de la sécurité.

leftaroundabout · Answer

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

Ce que vous entendez par la déclaration (correcte) selon laquelle ces "sont très vulnérables", c'est qu'il existe un algorithme plus facile à deviner pour les générer, à savoir "appuyez sur la ligne numérique d'un clavier QWERTY dans tel et C'est un algorithme facile à reconnaître pour un humain qui passe toute la journée à appuyer ses doigts sur un tel clavier, mais les motifs sur un tel clavier sont en fait plutôt "non évidents pour un ordinateur", car dans la plupart des programmes informatiques ne se soucient pas du tout de la disposition physique des touches^†.

Je pourrais tout aussi bien donner un exemple comme YWJjZGVmZ2hpamts, que vous pourriez penser être un mot de passe raisonnablement sûr, mais vous vous trompez en fait car il s'agit du codage Base64 de la chaîne abcdefghijkl, et cela peut sembler totalement évident vers une IA pour laquelle une chaîne est avant tout un motif binaire.

La notion de la simplicité avec laquelle un bit d'information 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 c'est non calculable. 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^‡ il ne garantit en aucun cas qu'il n'existe aucun moyen de faible entropie pour calculer le mot de passe dans une autre langue qui comprend une fonction standard cruciale. Si vous ne connaissiez pas la disposition QWERTY, vous pourriez également penser que asdfqwerzxcv est sûr, malgré l'évidence complète lorsque vous la connaissez.

Résultat: si vous trouvez une représentation à faible entropie d'un mot de passe donné, alors oui, interdisez-le. Mais ne prenez jamais l'affirmation de quiconque (y compris toute programme) à sa 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 non craquables, la seule façon est de vous assurer qu'ils sortent d'un processus aléatoire physique quantique.

^†_{Tout programme concerné par le craquage de mot de passe devrait connaît bien les dispositions du clavier, car il est bien connu que les humains ont tendance à recourir à de tels modèles. Aussi, 23##24$$25%%26 est assez facile même sans connaissant 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.}

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

reed · Answer

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 considérant uniquement les mots de passe alphanumériques). Et "12345678" peut être aussi difficile à casser que "4h2Ud8yG", si vous le forcez au hasard dans une plage de "00000000" à "ZZZZZZZZ". Mais la vérité est que les mots de passe ne doivent pas seulement être aléatoires, ils doivent aussi regarder 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ûrs. De plus, si des mots et des schémas sont utilisés pour rendre le mot de passe plus facile à mémoriser, il est probable que tous les autres mots de passe utilisés par la même personne seront plus faciles à mémoriser 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 en forçant des schémas de force brute tels que "nom + numéro", "Mot + numéro", ou certaines variantes. Mais si l'attaquant vole un de vos mots de passe et qu'il ressemble à "4h2Ud8yG", il ne pourra pas en extraire aucune information.

Vous avez donc raison lorsque vous dites que les 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 cela parce que l'entropie des mots de passe est basée sur la façon dont un mot de passe ressemble ou sur 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 "numéro suivi d'un symbole, six fois", vous auriez (10x10) ^ 6 = 10 ^ 12 possibilités. Ce qui est inférieur aux possibilités d'un simple mot de passe à 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 "numéro suivi d'un symbole sur la même clé, en commençant par 1 dans l'ordre croissant, six fois", alors les possibilités totales sont ... une seule!

keithRozario · Answer

Tout d'abord, ces indicateurs de résistance de mot de passe sont des lignes directrices, pas une vérité absolue.

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

Il existe 3 attaques courantes contre les mots de passe:

Les attaquants tentent de se connecter à un service en devinant le mot de passe
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 des informations d'identification)
Les attaquants ont obtenu le vidage de la base de données d'un service et disposent du hachage de mot de passe. Ils forcent désormais les hachages à déterminer le mot de passe en texte brut.

Pour empêcher les attaquants de deviner les mots de passe, nous appliquons une sorte de "règle d'entropie" [~ # ~] et [~ # ~] nous limitons la vitesse tentatives de connexion. De cette façon, les attaquants ne peuvent pas forcer directement votre service.

Il est plus difficile d'empêcher le bourrage des informations d'identification, quelle que soit la force avec laquelle vous forcez les mots de passe à être, cela ne sera d'aucune utilité si l'utilisateur avait le même mot de passe sur un système séparé et que 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 sociétés . Cela aide à protéger contre le bourrage des informations d'identification (un peu!), Mais pourrait être un peu trop loin.

Enfin, il y a le brute-forçage typique d'un hachage de mot de passe. C'est là qu'un attaquant s'est en quelque sorte emparé des hachages de mot de passe des utilisateurs et essaie maintenant de deviner le texte en clair des hachages. Voici où nous entendons couramment le il faudra des siècles pour se briser trope.

Typiquement, l'attaquant utilisera un outil comme ocl-hashcat en combinaison avec une liste de mots de mot de passe commun (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.

Pour ralentir l'attaque, nous comptons généralement sur:

Utilisation d'une fonction de hachage forte (Bcrypt au lieu de MD5)
Salage de mots de passe individuels (pour forcer les attaquants à utiliser 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 constitué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 DEVRAIENT comparer les secrets potentiels à 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.
Caractères répétitifs ou 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 une réinitialisation du mot de passe une fois qu'une violation est découverte sur leur service.

En bref, ne soyez pas confus de prendre des siècles pour briser le non-sens. 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.

Tom · Answer

La plupart des conseils en ligne sur les mots de passe sont, pour le dire conviviaux, 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'a admis l'année dernière - à sa sortie.

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

Votre menace pourrait être forçage brutal. 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é (mettez cela 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 consiste à saler et 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 et permutations simples du dictionnaire. Utilisez la même logique que celle utilisée par les crackers, certains d'entre eux sont accessibles au public.

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

Etc...

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

Peter Green · Answer

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 à briser.

De telles affirmations sont toujours très douteuses.

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

Un attaquant idéalisé essaierait les mots de passe dans l'ordre du plus probable au moins probable. Bien sûr, un véritable attaquant ne sait pas à quel point un mot de passe donné est probable, il doit donc deviner, il combinera généralement une sorte de dictionnaire (qui, si l'attaquant est quelque peu concurrent, contiendra beaucoup plus que des mots anglais normaux) avec un tas de règles de génération.

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

Le problème fondamental des restrictions de mot de passe est que, quelle que soit la restriction que vous effectuez, les utilisateurs font souvent le strict minimum pour faire passer leur mot de passe.

Maintenant, cela peut ajouter de l'entropie, il y a normalement plus d'une façon minimale 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 pourrait suggérer. Par exemple, si vous forcez les utilisateurs à ajouter un numéro à leur mot de passe, un nombre disproportionné d'entre eux est susceptible de choisir 1.

MauganRa · Answer

Vous êtes probablement confus en supposant qu'il est possible de définir la vulnérabilité de mot de passe a priori. Au lieu de cela, cela dépend fortement du modèle qu'un attaquant réel essaierait en premier. Un attaquant opportuniste essaierait probablement d'abord un dictionnaire ou des listes de mots de passe divulgués. Mais en mettant même un effort modéré, ils peuvent devenir assez précis. C'est une raison pour laquelle c'est une bataille perdue d'appliquer les directives sur les mots de passe. 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 à la place sur des 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 comme "minuscules, majuscules, chiffres et caractères spéciaux", un attaquant peut supposer que certains utilisateurs dérivent leur mot de passe en utilisant exactement ce modèle.
Il serait possible de leur indiquer si leur mot de passe était un mot de passe divulgué, mais il y a alors le risque qu'ils finissent 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 les avantages de l'utilisation 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. De plus, ils placent une limite supérieure sur l'effort le plus défavorable qu'un attaquant doit dépenser.

jmoreno · Answer

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

Afin de calculer correctement l'entropie d'un mot de passe, vous devez supposer que l'attaquant en sait autant sur la façon dont le mot de passe a été créé que le créateur. 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'ils sont.

De cela, 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 comprendre comment demander à quelqu'un d'autre de faire le mot de passe ou son équivalent.