Comment puis-je estimer l'entropie d'un mot de passe?
Ayant lu - diverses ressources À propos de la force de mot de passe Je tente de créer un algorithme qui fournira une estimation approximative de l'entropie d'un mot de passe.
J'essaie de créer un algorithme aussi complet que possible. À ce stade, je n'ai que pseudocode, mais l'algorithme couvre ce qui suit:
- longueur du mot de passe
- caractères répétés
- motifs (logiques)
- différents espaces de caractère (LC, UC, numériques, spéciaux, étendus)
- attaques de dictionnaire
Il ne couvre pas ce qui suit et devrait bien couvrir (bien que pas parfaitement):
- commande (les mots de passe peuvent être strictement commandés par la sortie de cet algorithme)
- motifs (spatial)
Quelqu'un peut-il donner une idée de ce que cet algorithme pourrait être faible? Spécifiquement, quelqu'un peut-il penser à des situations où l'alimentation d'un mot de passe à l'algorithme serait [~ # ~] surestimer [~ # ~] sa force? Les sous-estimations sont moins problématiques.
L'algorithme:
// the password to test
password = ?
length = length(password)
// unique character counts from password (duplicates discarded)
uqlca = number of unique lowercase alphabetic characters in password
uquca = number of uppercase alphabetic characters
uqd = number of unique digits
uqsp = number of unique special characters (anything with a key on the keyboard)
uqxc = number of unique special special characters (alt codes, extended-ascii stuff)
// algorithm parameters, total sizes of alphabet spaces
Nlca = total possible number of lowercase letters (26)
Nuca = total uppercase letters (26)
Nd = total digits (10)
Nsp = total special characters (32 or something)
Nxc = total extended ascii characters that dont fit into other categorys (idk, 50?)
// algorithm parameters, pw strength growth rates as percentages (per character)
flca = entropy growth factor for lowercase letters (.25 is probably a good value)
fuca = EGF for uppercase letters (.4 is probably good)
fd = EGF for digits (.4 is probably good)
fsp = EGF for special chars (.5 is probably good)
fxc = EGF for extended ascii chars (.75 is probably good)
// repetition factors. few unique letters == low factor, many unique == high
rflca = (1 - (1 - flca) ^ uqlca)
rfuca = (1 - (1 - fuca) ^ uquca)
rfd = (1 - (1 - fd ) ^ uqd )
rfsp = (1 - (1 - fsp ) ^ uqsp )
rfxc = (1 - (1 - fxc ) ^ uqxc )
// digit strengths
strength =
( rflca * Nlca +
rfuca * Nuca +
rfd * Nd +
rfsp * Nsp +
rfxc * Nxc ) ^ length
entropybits = log_base_2(strength)
Quelques entrées et leurs sorties de l'entropie souhaitée et réelle.
INPUT DESIRED ACTUAL
aaa very pathetic 8.1
aaaaaaaaa pathetic 24.7
abcdefghi weak 31.2
H0ley$Mol3y_ strong 72.2
s^fU¬5ü;y34G< wtf 88.9
[a^36]* pathetic 97.2
[a^20]A[a^15]* strong 146.8
xkcd1** medium 79.3
xkcd2** wtf 160.5
* these 2 passwords use shortened notation, where [a^N] expands to N a's.
** xkcd1 = "Tr0ub4dor&3", xkcd2 = "correct horse battery staple"
L'algorithme se rendit compte (correctement) qui augmente la taille de l'alphabet (même par un chiffre) renforce considérablement les mots de passe longs, comme indiqué par la différence d'entropie_bits pour les 6ème et 7e mots de passe, qui consistent tous les deux de 36 A, mais le 21ème du 21e A est capitalisé. Cependant, ils ne tiennent pas compte du fait qu'un mot de passe de 36 A n'est pas une bonne idée, il est facilement brisé avec un cracker de mot de passe faible (et quiconque qui vous regarde tape le verra) et l'algorithme ne reflète pas que .
Il reflète cependant le fait que XKCD1 est un mot de passe faible par rapport à XKCD2, malgré une plus grande densité de complexité (est-ce même une chose?).
Comment puis-je améliorer cet algorithme?
Addendum 1
Les attaques de dictionnaires et les attaques à base de motifs semblent être la grande chose, alors je vais prendre un coup de poignard pour résoudre ceux-ci.
Je pourrais effectuer une recherche complète via le mot de passe pour les mots d'une liste de mots et remplacer les mots avec des jetons uniques aux mots qu'ils représentent. Les jetons de mots seraient ensuite traités comme des caractères et avoir leur propre système de poids et ajouteraient leurs propres poids au mot de passe. J'aurais besoin de quelques nouveaux paramètres d'algorithme (je les appellerai LW, NW ~ = 2 ^ 11, FW ~ = .5, et RFW) et je ferais tout le poids dans le mot de passe comme je le ferais de l'autre. poids.
Cette recherche de mots pourrait être spécialement modifiée pour correspondre à la fois en minuscules et majuscules, ainsi que des substitutions de caractères communes, telles que celle de E avec 3. Si je n'ai pas ajouté de poids supplémentaire à de tels mots appariés, l'algorithme sous-estimerait un peu leur force par un peu. ou deux par mot, ce qui est ok. Sinon, une règle générale serait, pour chaque match de caractère non parfait, donnez le mot un bit de bonus.
Je pourrais ensuite effectuer des contrôles de modèle simples, tels que la recherche de pistes de caractères répétés et de tests dérivés (prenez la différence entre chaque caractère), ce qui identifierait des motifs tels que "AAAAA" et "12345" et remplacer chaque motif détecté avec un motif. jeton, unique au motif et à la longueur. Les paramètres algorithmiques (spécifiquement, entropie par motif) pourraient être générés à la volée en fonction du motif.
À ce stade, je prendrais la longueur du mot de passe. Chaque jeton de mot et chaque jeton compterait comme un seul caractère; Chaque jeton remplacerait les caractères qu'ils représentaient symboliquement.
J'ai composé une sorte de notation de motif, mais elle inclut la longueur de motif L, l'ordre de motif O et l'élément de base b. Ces informations pourraient être utilisées pour calculer un poids arbitraire pour chaque motif. Je ferais quelque chose de mieux dans le code actuel.
Exemple modifié:
Password: 1234kitty$$$$$herpderp
Tokenized: 1 2 3 4 k i t t y $ $ $ $ $ h e r p d e r p
Words Filtered: 1 2 3 4 @W5783 $ $ $ $ $ @W9001 @W9002
Patterns Filtered: @P[l=4,o=1,b='1'] @W5783 @P[l=5,o=0,b='$'] @W9001 @W9002
Breakdown: 3 small, unique words and 2 patterns
Entropy: about 45 bits, as per modified algorithm
Password: correcthorsebatterystaple
Tokenized: c o r r e c t h o r s e b a t t e r y s t a p l e
Words Filtered: @W6783 @W7923 @W1535 @W2285
Breakdown: 4 small, unique words and no patterns
Entropy: 43 bits, as per modified algorithm
La sémantique exacte de la manière dont l'entropie est calculée à partir de modèles est à la discussion. Je pensais quelque chose comme:
entropy(b) * l * (o + 1) // o will be either zero or one
L'algorithme modifié trouverait des défauts avec et réduirait la résistance de chaque mot de passe de la table d'origine, à l'exception de s^fU¬5ü;y34G<, qui ne contient aucun mot ou modèle.
Annexe A sur P46 de NIST SP 800-6 Parle des travaux de Claude Shannon , qui estime l'entropie de mot de passe à l'aide d'un certain nombre de bits En effet, il s'agit du document que le dessin animé XKCD utilise pour calculer les bits d'entropie. Spécifiquement:
- l'entropie du premier caractère est prise pour être de 4 bits;
- l'entropie des 7 prochains caractères est de 2 bits par caractère; Ceci est approximativement cohérent avec l'estimation de Shannon selon lequel "lorsque des effets statistiques s'étendant plus de 8 lettres sont considérés comme étant considéré comme l'entropie est d'environ 2,3 bits par caractère;"
- pour le 9e à travers le 20e caractère, l'entropie est prise pour être de 1,5 bits par caractère;
- pour les caractères 21 et au-dessus de l'entropie est pris pour être 1 bit par caractère;
- Un "bonus" de 6 bits d'entropie est attribué à une règle de composition qui nécessite des caractères majuscules et non alphabétiques. Cela oblige l'utilisation de ces caractères, mais dans de nombreux cas, les caractères ne se produiront qu'au début ou à la fin du mot de passe, et il réduit quelque peu l'espace de recherche total, de sorte que la prestation est probablement modeste et presque indépendante de la longueur du le mot de passe;
- Un bonus allant jusqu'à 6 bits d'entropie est ajouté pour un vaste chèque de dictionnaire. Si l'attaquant connaît le dictionnaire, il peut éviter de tester ces mots de passe et sera en tout cas en mesure de deviner une grande partie du dictionnaire, ce qui sera cependant les mots de passe sélectionnés les plus probables en l'absence d'une règle de dictionnaire. L'hypothèse est que la plupart des avantages de l'entropie de devinettes pour un test de dictionnaire accumulent des mots de passe relativement courts, car tout mot de passe long qui peut être mémorisé doit nécessairement être une "phrase de passe" composée de mots de dictionnaire, de sorte que le bonus décline à zéro à 20 personnages.
L'idée est qu'un système d'authentification choisirait certains niveaux d'entropie en tant que seuils. Par exemple, 10 bits peuvent être faibles, 20 moyens et 30 forts (chiffres cueillis arbitrairement à titre d'exemple, pas une recommandation). Malheureusement, le document ne recommande pas de tels seuils, probablement parce que la puissance de calcul disponible pour la force brute ou la supposition de mots de passe augmente au fil du temps:
À titre d'alternative à l'imposition d'un ensemble de règles spécifique arbitraire, un système d'authentification pourrait noter les mots de passe de l'utilisateur, à l'aide des règles énoncées ci-dessus et acceptez tout ce qui correspond à une norme d'entropie minimale. Par exemple, supposons que les mots de passe avec au moins 24 bits d'entropie étaient nécessaires. Nous pouvons calculer l'estimation d'entropie de "iamthecapitanofthepina4" en observant que la chaîne comporte 23 caractères et satisferait une règle de composition nécessitant des caractères majuscules et non alphabétiques.
Cela peut ne pas être ce que vous recherchez, mais n'est pas un mauvais point de référence, si rien d'autre.
[EDIT: Ajout des éléments suivants.]
Le papier tester les métriques de stratégies de création de mot de passe en attaquant de grands ensembles de mots de passe révélés (par Matt Weir, Sudhir Aggarwal, Michael Collins et Henry Stern), a démontré le modèle Shannon, décrit ci-dessus, n'est pas un modèle précis de entropie pour les mots de passe générés par l'homme. Je recommanderais de regarder "la section 5 générant de nouvelles stratégies de création de mots de passe" pour des propositions plus précises.
Consultez le code source pour Keepass en bas de cette page . La classe QualityEstimation implémente un algorithme plutôt bel qui semble être conforme à ce que vous cherchez à avoir en place. Mes résultats se ressemblent comme tels:
aaa 8
aaaaaaaaa 9
abcdefghi 18
H0ley$Mol3y_ 73
s^fU¬5ü;y34G< 99
[a^36]* 10
[a^20]A[a^15]* 18
Tr0ub4dor&3 66
correct horse battery staple 98
Tu demandes
Spécifiquement, quelqu'un peut-il penser aux situations où nourrir un mot de passe à l'algorithme surestimerait sa force?
Mais vous avez un exemple dans la question. Par design, XKCD2 a ~ 44 bits d'entropie, mais votre estimation est de 160,5 bits.
Quelqu'un peut-il donner une idée de ce que cet algorithme pourrait être faible? Spécifiquement, quelqu'un peut-il penser aux situations où nourrir un mot de passe à l'algorithme surestimerait sa force?
Vous avez laissé entendre certains dans le préambule (attaques de dictionnaire, etc.). Essentiellement, il existe un certain nombre de pratiques communes qui peuvent être devinées par l'attaquant qui réduit considérablement l'espace de recherche. Je suis à peu près sûr que votre algorithme "surestimera-t-elle" ce qui suit:
- partout
- Partout
- Partout1
Le mot de passe est assez long, mais est trivialement fissuable car le mot original apparaît dans un dictionnaire de base et les modifications sont considérées comme suffisamment courantes pour faire partie de toute attaque décente dictionnaire. Lettre typique -> Les conversions numériques (c'est-à-dire 3v3rhwh3r3) doivent également être considérées comme assez faibles et vous devriez pénaliser pour ceux-ci.
Pour un degré beaucoup moins important, d'autres mots de passe de problèmes peuvent être des modèles évidents, tels que:
- abcdefghijklmnop
- abcde12345
Bien que ceux-ci soient probablement moins susceptibles d'être ciblés dans des attaques de dictionnaires réels, elles souffrent de problèmes similaires que votre exemple "AAAAA ...".
Je ne sais pas si les phrases de mot de passe sont actuellement ciblées dans la plupart des attaques de dictionnaires, mais sans aucun doute en popularité, ils seront de plus en plus ciblés. Je pense que le célèbre exemple XKCD prend en compte cela, car seulement 11 bits sont attribués à chaque "mot commun". Votre algorithme surestime ces types de mots de passe.
Donc, pour résumer, l'algorithme fait un assez bon travail de l'estimation, mais il devrait vraiment prendre en considération la structure du mot de passe et des motifs communs connus.