Question:
Longueur des mots de passe sécurisés pour la table arc-en-ciel
rubo77
2014-06-10 05:17:22 UTC
view on stackexchange narkive permalink

Avec une grande puissance de calcul (comme ce que vous pouvez obtenir dans le cloud Amazon par exemple), vous pouvez générer d'énormes tables arc-en-ciel pour les mots de passe. Il semble également y avoir de grandes tables arc-en-ciel accessibles pour lesquelles vous devez payer.

Quelles sont les plus grandes tables que les services secrets pourraient éventuellement utiliser et quel est le nombre maximum de caractères que vous pouvez avoir pour le mot de passe?

Je me demande combien de temps les mots de passe doivent être pris en compte lorsque vous choisissez vous-même un nouveau mot de passe? (Ce n'est pas la question ici!)

Quelle est la longueur maximale du mot de passe que ces énormes tables arc-en-ciel souterraines (utilisées par les forces du mal ) hébergent?

Même un peu suffit pour résister aux tables arc-en-ciel si vous utilisez des hachages correctement salés.
Ce serait mieux, si quelqu'un découvrait jusqu'à quelle longueur ces tables arc-en-ciel souterraines sont. C'était ma question initiale, et elle n'a pas encore reçu de réponse. Je me demande pourquoi @TomLeek obtient autant de votes positifs
@TomLeek reçoit tellement de votes positifs, car il explique assez bien le malentendu sur lequel repose votre question. Comme il le dit, «la longueur maximale du mot de passe» n'est * pas pertinente * pour «ces énormes tables arc-en-ciel souterraines». La réponse n'est pas (sauf pour la petite annexe à la fin) sur la façon de créer un mot de passe fort, mais sur "quel mot de passe n'est pas menacé par ces tables arc-en-ciel". C'est ce que vous * vouliez * demander, même si vous ne vous en êtes pas rendu compte ;-)
Les tables arc-en-ciel sont totalement inutiles à moins que vous ne fassiez quelque chose d'horriblement mal dans votre hachage de mot de passe.
Six réponses:
#1
+78
Tom Leek
2014-06-10 06:31:23 UTC
view on stackexchange narkive permalink

La longueur du mot de passe et la taille de la table arc-en-ciel sont des harengs rouges. La taille n'a pas d'importance. Ce qui compte, c'est entropy.

Les tableaux arc-en-ciel ne sont pas vraiment pertinents ici, pour deux raisons principales :

  1. Construire la table coûte cher . Un tableau "couvre" un certain nombre de mots de passe possibles; appelons-le N . Il y a N mots de passe distincts qui seront interrompus dans le tableau. Aucun autre ne le sera. Il se trouve que chacun de ces N mots de passe doit avoir été haché lors de la construction de la table. En fait, beaucoup ont été hachés plusieurs fois; construire une table qui peut déchiffrer N mots de passe coûte environ 1,7 * N appels de hachage. C'est plus cher que la force brute. En fait, la force brute nécessite en moyenne 0,5 * N hachages, donc la construction de la table coûte plus de trois fois plus cher.

    Ainsi, une table arc-en-ciel ne vaut l'effort que si il peut être appliqué au moins quatre fois, sur quatre hachages de mots de passe distincts qui doivent être craqués. Sinon, c'est une grosse perte de temps.

  2. Les tableaux arc-en-ciel ne peuvent pas être appliqués plus d'une fois . C'est à cause des sels . Tout hachage de mot de passe qui a été déployé par un développeur avec plus de cellules cérébrales qu'un gorille utilise des sels, qui sont des paramètres de variation non répétés. L'effet des sels équivaut à utiliser une fonction de hachage différente pour chaque utilisateur. Puisqu'une table arc-en-ciel doit être construite pour une fonction de hachage spécifique, une à la fois, il s'ensuit qu'une table arc-en-ciel ne pourra déchiffrer qu'un seul hachage de mot de passe en tout. Combinez avec le point précédent: les tableaux arc-en-ciel ne sont tout simplement pas utiles.

Maintenant, bien sûr, il existe de nombreux systèmes déployés où les mots de passe ne sont pas hachés avec une compétence de niveau humain. Le développement piloté par Ape a abouti à de nombreux serveurs sur lesquels un simple hachage non salé est utilisé; et même des serveurs où les mots de passe sont stockés en texte clair ou un encodage maison facilement réversible. Mais on pourrait dire que si votre mot de passe doit être géré par de tels systèmes mal conçus, une entropie de mot de passe supplémentaire ne vous sauvera pas. Un système logiciel qui échoue complètement à appliquer des techniques saines et documentées pour protéger un mot de passe, qui est l'archétype des données secrètes sensibles, ne réussira probablement pas mieux dans aucun de ses autres composants. Le crumminess et la négligence dans la conception de logiciels sont comme des cafards: quand vous en voyez un, vous pouvez être sûr qu'il y en a des centaines d'autres à proximité.


Supposons maintenant qu'un hachage de mot de passe raisonnable a été utilisé, combinant des sels (pour vaincre les attaques basées sur des tables et parallèles) et la lenteur configurable (pour rendre le hachage plus cher). Par exemple. bcrypt. Cette réponse est un long exposé de la façon dont les mots de passe doivent être hachés.

Par exemple, considérons un serveur utilisant bcrypt, configuré de telle sorte que, sur ce serveur, la vérification d'un hachage de mot de passe prenne 0,01 s vaut du temps CPU. Cela permettrait toujours au serveur de gérer 100 connexions utilisateur par seconde, un chiffre extrêmement élevé, de sorte que le serveur ne consacrera pas vraiment beaucoup de sa puissance de calcul au hachage de mot de passe.

Maintenant, imaginez un attaquant qui a obtenu ses mains sur des hachages de mots de passe, tels que stockés sur le serveur (par exemple, il a volé une ancienne sauvegarde, ou a utilisé une attaque par injection SQL pour récupérer des parties de la base de données). Puisque bcrypt est salé, l'attaquant devra payer le coût total de l'attaque par force brute sur chaque mot de passe; il n'y a pas de partage des coûts parallèle possible et, en particulier, aucune table précalculée (arc-en-ciel ou non) ne s'appliquerait.

Notre attaquant est puissant: il loue cent serveurs aux capacités de calcul similaires au serveur attaqué. Cela se traduit par 10000 tentatives de mot de passe par seconde. Aussi, l'attaquant est patient et dévoué: il accepte de passer un mois de calcul sur un seul mot de passe (de sorte que le mot de passe doit protéger certains actifs très précieux). En un mois à 10000 mots de passe par seconde, c'est environ 26 milliards de mots de passe qui seront essayés.

Pour vaincre l'attaquant, il suffit donc de choisir des mots de passe avec suffisamment d'entropie pour réduire la probabilité de succès de l'attaquant à moins de 1/2 dans ces conditions. Puisque 26 milliards est proche de 234,6 , cela signifie que l'entropie du mot de passe doit être d'au moins 35,6 bits .

L'entropie est une caractéristique de la méthode utilisée pour générer le mot de passe, et n'est que faiblement corrélée avec la longueur. Le mot de passe ne signifie pas la force; la longueur est juste nécessaire pour faire de la place pour l'entropie. Par exemple, si vous générez un mot de passe sous la forme d'une séquence de lettres aléatoires (majuscules et minuscules), alors 7 caractères accumulent près de 40 bits d'entropie, ce qui, d'après les calculs effectués ci-dessus, devrait convenir. Mais cela nécessite absolument que les lettres soient choisies au hasard, uniformément et indépendamment les unes des autres. Peu d'utilisateurs feraient l'effort d'utiliser un ordinateur PRNG pour produire un nouveau mot de passe, puis accepteraient de l'apprendre tel qu'il a été généré (je le fais, mais quand je l'explique à mes collègues de travail, ils me regardent dans un étrange manière).

Comme l'indique cette fameuse question, la mémoire humaine peut être en contradiction avec l'entropie, et un mot de passe plus long avec plus de structure peut être un meilleur compromis. Considérez que la méthode du «cheval correct» se termine par «seulement» 44 bits d'entropie pour environ 25 lettres (au fait, notez qu'un mot de passe de 25 lettres peut avoir moins d'entropie qu'un mot de passe de 8 lettres). Cependant, la saisie supplémentaire peut valoir la peine si elle permet à un utilisateur moyen de se souvenir d'un mot de passe d'entropie de 40 bits.


Malgré toute la propagande des films hollywoodiens, les services secrets impliquent rarement une technologie incroyablement avancée (d'ailleurs, ils sont également assez courts sur les Martinis secs, les blondes aux longues jambes et les courses en moto). Tout service secret géré rationnellement évitera de dépenser 10k $ pour casser votre mot de passe, car 1k $ sera plus que suffisant pour embaucher deux crétins pour casser vos rotules. En fin de compte, tout est une question de coût relatif.

Soyons pratiques. Pour générer un mot de passe, utilisez cette commande sur un système Linux:

  dd if = / dev / urandom bs = 6 count = 1 2> / dev / null | base64  

Ceci génère un mot de passe composé de huit caractères parmi les lettres minuscules, majuscules, chiffres, «/» et «+». Il est facile de montrer que chacun de ces mots de passe offre 48 bits d'entropie. Les règles importantes sont les suivantes:

  1. Générez le mot de passe puis acceptez-le . N'allez pas en produire un autre si vous n'aimez pas ce que vous avez. Toute stratégie de sélection réduit votre entropie.
  2. Ne réutilisez pas les mots de passe . Un mot de passe pour chaque site. C'est la règle de limitation des dégâts la plus importante. Si vous avez du mal à vous souvenir de nombreux mots de passe, vous pouvez les «noter» (des gestionnaires de mots de passe comme KeePass peuvent vous aider).
  3. Si 48 bits d’entropie ne suffisent pas, vous êtes en utilisant un mot de passe dans un système faible, et c'est ce que vous devez corriger.
  4. Vos ennemis sont après votre argent, pas votre liberté. N'essayez pas de vaincre les agences fantasmagoriques à trois lettres; se concentrer sur les criminels banals.
La règle * acceptez ce que vous avez * a du sens, mais il y a une mise en garde. Parfois, ce n'est pas pratique. La probabilité que vous ayez oublié le mot de passe et que vous deviez le réinitialiser dépend du mot de passe que vous avez obtenu. Cela va se comporter comme une stratégie de sélection. La seule solution à laquelle je puisse penser est un peu de marge de sécurité en termes d'entropie. Vous pouvez modifier la règle et dire que vous êtes autorisé à supprimer autant de mots de passe que vous le souhaitez, mais à chaque fois que vous le faites, l'entropie du nouveau mot de passe doit être un peu plus élevée que la précédente.
J'ai juste essayé cette commande. 90% n'a pas de caractères spéciaux. Seuls les caractères spéciaux que je vois sont «/» et «+». Quel est le jeu de caractères ici?
Serait-il utile de créer un mot de passe aléatoire de 8 caractères comme `PB0oW + dr`, puis de l'utiliser deux fois?
Le jeu de caractères de `base64` est le jeu de caractères de [Base64] (http://en.wikipedia.org/wiki/Base64). Comme je l'ai écrit: lettres minuscules, lettres majuscules, chiffres, «+» et «/».
"Utiliser le mot de passe deux fois" fait à peu près autant de bien pour la sécurité que de sacrifier une chèvre pour apaiser les dieux. Faites-le si vous vous sentez plus en sécurité, mais scientifiquement un tel doublement n'améliore pas l'entropie (l'entropie est "ce que l'attaquant ne sait pas", et il sait que vous écrivez le mot de passe deux fois parce que vous venez de l'avouer sur un forum public).
@SPRBRN Les caractères spéciaux ne sont pas plus sûrs que les lettres, ce qui compte, c'est le nombre total de caractères possibles. L'utilisation d'un mot de passe composé de la même chaîne répétée deux fois le rend plus long, mais ajoute au plus un bit d'entropie (si vous lancez une pièce pour décider d'utiliser le mot de passe court ou long, et que l'attaquant ne connaît pas la longueur de votre mot de passe): ça ne vaut pas le coup.
En ce qui concerne «Ne pas en produire un autre»: il est normal de redessiner si vous n'en aimez pas un; si vous redessinez * N * mots de passe, l'entropie n'est réduite que de log₂ (N) bits, par ex. si vous générez 16 mots de passe et en choisissez un, vous obtenez toujours un 48-log₂ (16) = 44 bits d'entropie acceptable. Ce que vous ne devez pas faire, c'est générer un mot de passe et l'ajuster mentalement à quelque chose que vous préférez: cela réduit très rapidement l'entropie.
`dd` est un programme un peu bruyant et ne correspond pas parfaitement à la tâche. C'est plus simple: `head -c 6 / dev / urandom | base64`
Je suis probablement un peu pédant, mais `/ dev / urandom` ne réutilise-t-il pas le pool d'entropie du noyau s'il n'en reste pas assez? Donc, si nous voulons nous rapprocher le plus possible de 48 bits d'entropie, nous ferions bien d'utiliser `/ dev / random`, non?
"48 bits d'entropie" LOL c'est un conseil terrible. Joe se l'appropriera pour cela dans la pratique parce que les sites sont effectivement "cassés" comme vous le dites, et il n'a aucun moyen de le savoir. Si vous utilisez un gestionnaire de mots de passe, Joe choisira des passes déraisonnablement énormes dans un grand alphabet et sera en sécurité (48 bits ne s'appliquent pas). S'il n'y a pas de gestionnaire de mots de passe (je suppose que vous le considérez comme facultatif puisque vous suggérez 48 bits), Joe va réutiliser certains mots de passe, et il est très probable que l'un des sites sur lesquels il a réutilisé le mot de passe soit "faible" et révèle son mot de passe .
@Longpoke «Si aucun gestionnaire de mots de passe»: non, le gestionnaire de mots de passe n'est pas facultatif. Si vous donnez votre mot de passe à deux sites, toute personne qui enfreint l'un peut violer votre compte sur l'autre site - ce n'est pas bon. 48 bits d'entropie est un bon conseil (un peu sûr, mais un bon nombre rond, et mieux vaut prévenir que guérir).
Ok .. (en ignorant que vous prétendez savoir ce qu'il voulait dire) mais que faire si le site utilise du sha1 ordinaire (ou même avec un sel)? Ensuite, 48 bits seront fissurés en 7 heures avec 10 ^ 10 hachages / seconde.
Quand j'écris «ne pas réutiliser les mots de passe», je veux dire «ne pas réutiliser les mots de passe». Dans ma franchise, j'ai pensé que cela aurait été clair.
Cela signifie que l'utilisateur doit utiliser un gestionnaire de mots de passe (papier ou électronique [à moins que votre avis ne concerne uniquement un mot de passe principal et non un ensemble de mots de passe Web]), et ainsi prendre le risque de 48 bits d'entropie est inutile.
Je ne suis pas d'accord que le redessin réduit l'entropie, tant qu'il n'est pas basé sur une règle connue. Lors de la création d'une clé publique, j'ai refait le processus plusieurs fois jusqu'à ce que le tirage au sort soit "beau", mais vous auriez besoin d'un modèle complet de mes goûts artistiques pour savoir lesquels sembleraient "bons" ou "mauvais". l'entropie est la même. Et j'ai une belle clé privée.
@Davidmh Faire quelque chose «qui n'est pas basé sur une règle connue» réduit l'entropie. Pour maintenir l'entropie, vous devez choisir au hasard, et non en fonction d'une règle inconnue. Si vous décidez au hasard de redessiner, cela ne réduit pas l'entropie… mais cela n'aide pas.
Les raisons esthétiques d'@Gilles sont aussi proches que aléatoires. J'ai annoncé publiquement que ma clé privée était "jolie", comment quelqu'un peut-il l'utiliser pour aider lors d'une attaque?
@Davidmh Non, les raisons «esthétiques» (pas vraiment le mot juste) ne sont pas aléatoires. Ils sont trop personnels pour être modélisés avec précision, mais nous ne recherchons pas la précision ici. Les raisons de ne pas redessiner sont basées sur des modèles que les humains peuvent repérer, ce qui réduit considérablement l'espace de recherche. Vous pouvez mesurer combien en voyant le nombre de coups qu'il faut jusqu'à ce que vous abandonniez et en sélectionniez un.
@Gilles connaissant la longueur du mot de passe réduit l'espace de recherche. Sachant qu'un hachage aléatoire remplit certaines conditions arbitraires inconnues, ce n'est pas le cas. De plus, votre mot de passe obtenu au hasard _pourrait_ être `aaa1234` (il y a une probabilité non nulle que cela se produise), mais même si l'entropie est aussi élevée que possible, elle pourrait être facilement fissurée, surtout si l'attaquant ne sait pas comment vous l'ont généré et essaie les basiques.
Suis-je le seul gêné par des choses comme "un mot de passe avec 40 bits d'entropie"? Cela n'a pas de sens de parler d'entropie d'un seul mot de passe, l'entropie est une métrique d'un ensemble de choses. Votre recommandation augmente en fait l'entropie en augmentant le sous-ensemble de mots de passe de N caractères de "Mots / phrases anglais de longueur N" à "toutes les chaînes codées en base64 de longueur N". Le explique la discussion sur le redessiner: si vous redessinez jusqu'à ce que vous trouviez des "chaînes codées en base64 de longueur N d'apparence anglaise", vous réduisez l'entropie en réduisant la taille du sous-ensemble.
Bonne réponse. J'ai créé un compte ici juste pour le voter.
* Développement axé sur les singes *, magnifique. Aussi, bien expliqué.
La longueur est la caractéristique la plus importante. Entroy grandit avec une longueur beaucoup plus rapide que l'ensemble de caractères. Un mot de passe numérique aléatoire a 3,3 bits par chiffre. Un mot de passe composé d'un choix de 72 (supérieur, inférieur, chiffres et dix spéciaux) a 6,1 bits par chiffre. Un mot de passe tiré uniquement de chiffres ne doit être que deux fois plus long pour avoir une sécurité comparable. .... .... .... *** longueur, longueur, longueur, longueur ***
#2
+5
Philipp
2014-06-16 16:27:48 UTC
view on stackexchange narkive permalink

En supposant des hachages de 256 bits (32 octets) et en supposant que vous vouliez couvrir tous les mots de passe possibles avec 80 caractères différents (26 minuscules, 26 majuscules, 10 chiffres, 18 autres caractères), ce sont les tailles de table arc-en-ciel requises. J'ai calculé cela en utilisant la formule (80 ^ longueur) * (32 + longueur) .

Cependant, gardez à l'esprit que le tableau ci-dessous concerne toutes les combinaisons possibles de 80 caractères différents . Lorsque vous utilisez moins de caractères ou que vous créez uniquement des hachages pour les mots de passe qui suivent certains modèles (comme toutes les permutations de mots l337speak dans le dictionnaire), vous vous retrouvez avec beaucoup moins d'espace.

  Longueur Taille Unité 1 2,5 KiloByte 2212 KiloByte3 17 MegaByte4 1,3 GigaByte5 112 GigaByte6 9 TeraByte7 744 TeraByte8 59 PetaByte9 4,7 ExaByte10 391 ExaByte11 31 ZettaByte12 2,5 Yide pour l'ordre de 

vous-même

l'ampleur est toujours dans les capacités techniques plausibles des attaquants que vous considérez. Mais quand vous voulez mon avis, je pense que:
  • Une table arc-en-ciel à 5 ​​caractères (112 Go) est suffisamment petite pour l'échanger sur Internet haut débit d'aujourd'hui
  • 6 caractères (9 To) est la limite de ce qu'un amateur ou un cracker professionnel indépendant peut gérer avec du matériel de grande consommation
  • Une table arc-en-ciel à 7 caractères (744 To) s'intégrerait dans un rack SAN dans un centre de données, donc ce serait dans les capacités techniques d'une entreprise professionnelle de stocker une telle table.
  • Une table arc-en-ciel à 8 caractères avec 59 Po est techniquement assez difficile, mais des bases de données de cette échelle existent: Facebook gère une base de données avec plus de 100 Po de données, le CERN a une base de données de 200 Po de données générées par le Expériences LHC. Il est donc à la portée d'une très grande entreprise ou d'une agence gouvernementale avec un budget d'un million de dollars.
  • 9 caractères et plus semblent peu plausibles avec la technologie actuelle.
Ainsi, 7 caractères représentent déjà 744 To de données pures à stocker pour un seul sel. Combien une base de données utiliserait-elle pour les stocker? Je suppose que c'est beaucoup moins, car les données sont stockées compressées
Les hachages @rubo77 sont des données qui sont déjà aussi denses que possible, donc elles ne peuvent pas être compressées davantage. Cela signifie que vous pouvez supposer que le stockage réel de la base de données serait plus que inférieur.
Anecdote: Lorsque vous développez un moyen de stocker un bit d'information dans un seul atome, puis de convertir toute la planète Terre en un magasin de données atomiques, vous pouvez y stocker une table arc-en-ciel de 25 caractères.
#3
+4
Stephen Ostermiller
2014-06-10 21:33:51 UTC
view on stackexchange narkive permalink

Je suis l'auteur du site Web http://passwordcreator.org/. J'ai construit le site parce que je voulais un moyen plus simple de générer des mots de passe sécurisés pour moi-même. En faisant des recherches pour le site, j'ai beaucoup appris sur les mots de passe sécurisés.

Il existe des crackers de mots de passe distribués qui peuvent faire 100 milliards de suppositions par seconde. La NSA qui est parrainée par le gouvernement (gros budget) peut être en mesure de faire un ordre de grandeur de plus.

Pour être à l'abri pendant un an ou plus de ce type d'attaque, votre le mot de passe doit être choisi au hasard parmi plusieurs quintillions de possibilités. Pour un mot de passe construit au hasard à partir des 95 caractères disponibles sur la plupart des claviers, cela signifie que vous avez besoin d'un mot de passe d'au moins 10 caractères pour une sécurité décente dès maintenant.

Si vous Le mot de passe est généré d'une autre manière (il existe plusieurs algorithmes disponibles sur mon site), votre mot de passe devra peut-être être encore plus long pour obtenir la même résistance contre les devinettes.

A 10 caractères, je dois bien écrire bas mon mot de passe aléatoire. Si tel est le cas pour vous également, je vous recommande d'augmenter la longueur à au moins 14 caractères, ce qui restera sécurisé pendant plus longtemps.

S'agit-il de comparaisons de chaînes 1e11 de 10 caractères, de calculs 1e11 SHA-1 ou de calculs 1e11 PBKDF2 avec un nombre d'itérations décent? Parce que nous parlons ici de craquage de mot de passe hors ligne.
Pas de comparaisons de chaînes, de calculs SHA-1. Je sais que ce n'est pas la meilleure façon de hacher les mots de passe, mais lorsque vous créez un mot de passe qui est stocké dans la base de données de quelqu'un d'autre, il est préférable de supposer qu'il ne l'a pas mis en œuvre idéalement. Voir: https://security.stackexchange.com/questions/43683/is-it-possible-to-brute-force-all-8-character-passwords-in-an-offline-attack
#4
+4
tylerl
2014-06-11 04:43:36 UTC
view on stackexchange narkive permalink

Pour répondre à votre question révisée:

Quant à la longueur maximale du mot de passe précalculée, il n'y en a pas. Les hachages de mots de passe précalculés sont précalculés à partir de dictionnaires et non à partir d'analyses séquentielles de l'espace de clés. Bien qu'une génération séquentielle de mots de passe très courts puisse être courante, elle ne se résume généralement pas à quelques caractères. L'espace requis pour stocker tous les hachages de 256 bits pour les mots de passe à 8 caractères est de l'ordre d'exaoctets; pas au-delà de la capacité technique, mais certainement au-delà de toute sorte de considération coût-bénéfice.

De plus, si le serveur stockant les mots de passe utilise des sels pour chacun d'eux, alors toute l'idée de précalcul disparaît. Terminé. Pas de tables arc-en-ciel. Ils ne fonctionnent plus. Les hachages salés résistent aux tables arc-en-ciel, comme expliqué ici.

Pourtant, vous y pensez mal

La longueur du mot de passe est totalement hors de propos. Tout ce qui compte - la seule chose qui compte, c'est combien de mots de passe l'attaquant essaiera-t-il avant de deviner le bon , et combien de temps prend chaque estimation?

Si l'attaquant devine d'abord votre mot de passe, alors aucune complexité ne vous sauvera, et aucune complexité de stockage côté serveur ne vous sauvera. Il est aussi facile pour l'attaquant de se connecter que pour vous. Fin de la partie.

Si votre mot de passe est sur la liste, mais qu'il est à 500 depuis le haut, alors le temps nécessaire à l'attaquant pour accéder au vôtre est 500 fois le temps que prend chaque tentative. Si cela prend 1 seconde par mot de passe, alors vous avez environ 8 minutes. L'attaquant abandonnera-t-il après 5 minutes? S'il le fait, vous êtes en sécurité. S'il ne le fait pas, vous ne l'êtes pas.

Selon votre point d'origine, si votre mot de passe est dans la liste des 500 premiers, alors les hachages précalculés seront disponibles. Évidemment, cela n'a d'importance que si les mots de passe ne sont pas stockés salés.

Si votre mot de passe est aléatoire et provient d'un espace de clé de 48 bits (environ 8 caractères alphanumériques), alors en moyenne l'attaquant devra essayer l'attaquant doit essayer 2 47 mots de passe avant arriver à la vôtre. Combien de temps est-ce que cela prendra? Si les mots de passe sont stockés avec PBKDF2 réglé à ⅕ seconde par attampt (comme LUKS l'utilise), alors il faudra un peu moins d'un million d'années pour deviner votre mot de passe.

D'un autre côté, avec le même mot de passe , s'il a le matériel pour essayer 5 millions de suppositions par seconde, alors vous êtes à un peu moins d'un an. 5 milliards et c'est moins d'un jour.

Une meilleure façon de le faire

Mon conseil est d'utiliser un mot de passe aléatoire et impossible à deviner que vous ne faites pas souvenez-vous, mais stockez plutôt dans un gestionnaire de mots de passe intégré au navigateur comme KeepPass, LastPass ou 1Password. Dans ce cas, il n'y a pas de coût supplémentaire pour vous entre 6 et 24 caractères, vous pouvez donc aussi bien choisir un long - disons 14 ou 18 caractères. Cela devrait être plus que suffisant.

La clé ici est le gestionnaire de mots de passe intégré au navigateur. Un attaquant devinant votre mot de passe aléatoire n'est pas le vecteur d'attaque dont vous vous souciez. Ça n'arrivera pas. Au lieu de cela, vous vous souciez du phishing. C'est beaucoup plus probable, et les gestionnaires de mots de passe intégrés au navigateur vous sauveront.

Comment êtes-vous arrivé à une si grande taille de table arc-en-ciel? Mon estimation n'était que de 100 Go environ. Mais je ne suis guère un expert des tables arc-en-ciel, donc je ne suis peut-être pas là.
@CodesInChaos Si vous utilisez des * vraies * tables arc-en-ciel avec tout ce système de chaînage, vous pouvez les compresser un peu. Mais je ne parle que de simples ensembles de précalcul de recherche indexée, comme on le voit sur la plupart des sites Web.
L'utilisation d'un gestionnaire de mots de passe introduit un point de défaillance unique. La base de données de mots de passe moyenne est verrouillée avec un mot de passe simple dont le propriétaire peut facilement se souvenir. Comme aucun des mots de passe stockés n'est mémorisé (car le propriétaire ne fait que les copier-coller au lieu de les saisir), la base de données de mots de passe doit être sauvegardée régulièrement et portée sur différents périphériques. Quiconque mettra la main sur la base de données pourra ainsi toujours accéder à l'ensemble de vos comptes dès qu'il déchiffrera un seul mot de passe simple. Pire encore, les gens stockent même leurs identifiants bancaires dans leurs coffres-forts de mots de passe de nos jours.
Je sais que les gens l'utilisent pour plus de commodité, moi aussi, mais je n'oserais jamais recommander de les utiliser comme solution unique pour toute votre sécurité Web.
@Robbert bien que je comprends votre opinion, vous devez regarder le profil d'attaque et la meilleure ou la plus probable alternative à toute solution. Vous ne pouvez pas dire * ne faites pas X * sans fournir une solution en même temps. La recommandation naïve «d'utiliser des mots de passe aléatoires uniques pour tout et de les mémoriser tous» est théoriquement idéale mais au-delà de l'intenable. Cela n'arrive jamais parce que cela ne peut pas arriver. Vous avez besoin d'une solution concrète conçue en examinant quelle attaque est probable et construite à partir de là.
D'accord. Quoi qu'il en soit, ne pas compter sur une seule stratégie permet de garder les choses en sécurité.
Ces gestionnaires de mots de passe ne sont pas déverrouillés avec un "mot de passe simple".Il existe également une longue clé secrète dont vous avez besoin pour déverrouiller votre compte si vous utilisez pour la première fois sur un appareil.Et pourquoi diable choisiriez-vous un "mot de passe simple" comme clé principale ...
#5
+2
Bruno Rohée
2014-06-16 17:40:59 UTC
view on stackexchange narkive permalink

De l'excellent blog de Robert Graham http://blog.erratasec.com/2011/06/password-cracking-mining-and-gpus.html

Ceci est seulement vrai pour les mots de passe aléatoires, avec un attaquant effectuant une recherche exhaustive. Lorsque vous attaquez des mots de passe de personnes réelles, vous essayez d'abord d'autres approches.

Economics of password cracking

#6
+1
Mac
2015-04-29 00:35:36 UTC
view on stackexchange narkive permalink

La réponse acceptée par Tom Leek est excellente. L'entropie est importante ici, mais uniquement dans son contexte. La longueur du mot de passe ne doit pas être négligée.

Son exemple d'une chaîne de 8 caractères prise à partir d'un pool de casse mixte, de chiffres et de "+ /" pour créer un mot de passe ayant "une coqueluche de 48 bits d'entropie" est trompeur. Voici pourquoi:

Environ deux ans avant que cette question ne soit posée, il existait, en 2012, des clusters de 25 GPU qui pouvaient parcourir tous les mots de passe de huit caractères contenant des majuscules et des minuscules. -les lettres, chiffres et symboles en moins de 6 heures.

Nous sommes en 2015, et bien que l'entropie soit la clé, une chaîne de 8 caractères ne sera jamais suffisamment sécurisée, car dans une recherche exhaustive de mots de passe, la longueur est le facteur clé , pas l'entropie!

Par exemple, il y a trois ans le mot de passe Fail! 007 , avec tous ses aléatoire, pourrait être forcé brutalement dans 5,5 heures, mais la phrase de passe c'est un échec ne le pourrait pas. Pour comprendre pourquoi nous devons examiner la Taille de l'espace de recherche, ou la somme totale de tous les mots de passe possibles avec la taille de l'alphabet jusqu'à et y compris la longueur du mot de passe.

Échec! 007 avec huit caractères (supérieur, inférieur, numérique et symbole), a un espace de recherche de 6 704 780 954 517 120 ou 6,70 x 10 15 . Pourtant, la phrase secrète c'est un échec , six caractères de plus (tous de simples lettres minuscules), se trouve dans l'espace de recherche de 6 300 168 733 803 741 204 487 980 ou 6,30 x 10 24 possibilités. C'est une énorme différence.

Si nous pouvions essayer cent mille milliards de suppositions par seconde, Fail! 007 tomberait en 67 secondes. Cependant, c'est un échec , il faudrait 20 siècles pour rechercher de manière exhaustive l'espace.

Même la phrase légèrement juvénile 8 est 2 petits prendrait 3,7 ans et tiendrait bien plus longtemps que le plus imprévisible Fail! 007

La longueur prime sur l'entropie.

Pour résumer, pensez à passer phrase , pas à passer mot et faites en sorte que votre identifiant dépasse huit caractères. Même si vous vous êtes renseigné à leur sujet, comme l'a souligné Tom, Rainbow Tables ne sera pas utilisé dans l'attaque. Au lieu de cela, je pense qu'un pirate informatique dédié utilisera du matériel dédié qui, il y a trois ans, ne pouvait déchirer que quelques combinaisons de mots de passe 958 en cinq heures et demie.

Les Rainbow Tables ne sont pas la menace, le matériel dédié au cracking l'est. Imaginez ce que ce matériel sera capable de faire demain.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...