La génération aléatoire de mots de passe à partir d'un assortiment de mots du dictionnaire est-elle sécurisée sur le plan cryptographique?
Nous devrions tous connaître la bande dessinée XKCD sur la force des mots de passe , suggérant (de manière appropriée) qu'un mot de passe basé sur multiple les mots courants sont plus sûrs et mémorisables qu'un mot de passe tel que Aw3s0m3s4u(3 ou quelque chose.
J'ai une application (multi-plateforme) pour laquelle je veux générer des mots de passe quelque peu sécurisés, et mes exigences de mot de passe sont beaucoup moins exigeantes: si le mot de passe n'a pas d'espaces, je m'attends à ce que 'plusieurs symboles, chiffres, alpha mixte et 6+ caractères' , mais si le mot de passe a plus d'un espace non consécutif Je relâche la contrainte symbole/nombre/casse mixte, et exige à la place au moins deux mots qui ne sont pas moins de 4 caractères individuellement, avec une longueur de mot de passe minimale de 15 caractères.
La question n'est pas de ça aspect, mais de générer: en supposant que je veux générer un mot de passe facile à mémoriser et difficile à deviner pour l'utilisateur, est-il cryptographiquement sûr de générer un mot de passe basé sur environ 5 mots du dictionnaire d'une liste de 10 000 mots? (Littéralement, 10 000 mots se trouvent dans ma base de données, extraits de diverses sources, e-mails, etc.) Ce sont tous des mots assez courants, pas moins de 3 caractères.
Maintenant, je n'ai pas veux pour faire ces mots de passe à usage unique, mais je soupçonne que je devrais au moins obliger l'utilisateur à le changer pour autre chose lors de la connexion après avoir utilisé ce mot de passe généré, ce qui est bien et je peut, mais je veux également que les utilisateurs aient la possibilité (lors de la modification d'un mot de passe) de générer un mot de passe "sécurisé" qui correspond à mon exigences.
Du point de vue du cracking, serait-il facile/difficile d'attaquer un mot de passe généré à l'aide de ce schéma? Il n'y a pas de longueur fixe, les mots de cette table de base de données vont de 3 à 11 caractères (environment est un mot dans la base de données, par exemple)? Le programme générant les mots de passe ne choisira pas deux mots avec 4 caractères ou moins (donc le mot de passe le plus court pourrait être un mot à trois caractères, 4 à cinq caractères mots et 4 espaces, pour un total de 27 caractères), et il n'utilisera pas deux fois le même terme dans un mot de passe.
Sur la base des exemples que j'ai exécutés, la longueur moyenne des mots de passe générés par le programme est d'environ 34 caractères, ce qui me semble acceptable. Même si nous supposons que chacun des 27 caractères non-espace minimum (donc 23 caractères à la fin) peut être 26 états possibles (a-z), c'est 23^26 ou 2.54e+35 possibilités.
La base de données contient 994 mots de 3 à 4 caractères.
Nous pouvons également supposer que l'attaquant a le dictionnaire, et les paramètres/algorithme de génération. Est-ce toujours sécurisé, puis-je m'en tirer en supprimant un mot du mot de passe généré (c'est toujours 21 caractères, pour 18^26 possibilités (4.33e+32) basé sur l'entropie seule), le seul problème que je vois est que ce n'est pas basé sur caractère entropie, mais sur l'entropie Word, ce qui signifierait que le mot de passe à 5 mots est 10000*9006*9005*9004*9003 possibilités, ou 6.5e+19 possibilités, et le mot de passe à 4 mots est 10000*9006*9005*9004 possibilités, ou 7.30e+15. Par rapport à un mot de passe normal à 6 caractères ((26+26+10+33)^6 ou 7.35e+11 possibilités: 26 alpha inférieur, 26 alpha supérieur, 10 Nombres, 33 symboles) c'est nettement plus fort.
Une autre hypothèse que j'ai faite: les utilisateurs le feront écrivez ceci, ils le font toujours. I suspect que cinq mots aléatoires sur un morceau de papier (espérons-le pas dans direct vue, mais hélas c'est le scénario le plus probable) sont moins susceptibles d'être ramassé comme un mot de passe potentiel qu'un terme, eh bien, complexe qui ressemble comme un mot de passe traditionnel.
Enfin, avant d'arriver à mes vraies questions, les mots de passe sont tous salés avant d'être stockés dans la base de données, puis hachés avec le SHA-512 algorithme 100 fois, le sel étant ajouté entre chaque hachage. Si l'utilisateur se connecte correctement, le sel est modifié et un nouveau hachage de mot de passe est créé. (Je suppose que cela n'aide pas beaucoup dans une attaque hors ligne par force brute, mais je pense que cela devrait aider contre les attaques en ligne actives.)
DatabasePassword = SHA512(...SHA512(SHA512(SHA512(password + salt) + salt) + salt) + salt)...)
Donc, enfin, mes réelles questions:
- Mes calculs sont-ils corrects? (Vous n'avez pas nécessairement à répondre à cela, je suis sûr qu'il est suffisamment proche en principe pour démontrer mes préoccupations.)
- Est-ce génération sécurisé ou dois-je m'en tenir à la génération de mot de passe "traditionnelle"? Notez qu'un attaquant n'a pas n'importe quel idée si le mot de passe des utilisateurs a été généré avec cet algorithme ou sélectionné par l'utilisateur, l'attaquant peut faire une supposition si ils connaissent la longueur, mais cela peut être sûr ou non.
- Enfin, ai-je fait des hypothèses qui pourraient significativement altérer (augmenter ou diminuer) la sécurité de cette 'idée'? (En supposant que l'entropie par caractère d'un mot de passe à 6 caractères est de 95, par exemple.)
Toutes mes excuses pour la longueur, je suis habitué à me sur-expliquer pour j'espère apaiser la confusion.
Il a été souligné que ma question est extrêmement similaire à celle-ci , je tiens à souligner les différences dans ma méthode de génération (bien que, honnêtement, elle soit encore assez similaire qu'il pourrait être considéré comme un doublon, je laisse cela à la communauté de décider):
- Chaque mot est séparé par un espace, ce qui signifie que tous les caractères, sauf le premier et le dernier, ont un état potentiel supplémentaire.
- Le mot de passe est pas sélectionné par un humain, c'est (principalement) une génération aléatoire uniforme. Aucun mot n'est préféré aux autres sauf pour seulement autoriser un mot ultra-court (3 ou 4 caractères), une fois que le générateur aléatoire sélectionne un mot de cette longueur, plus aucun de ceux-ci ne peut être sélectionné. (Bien que la position selon laquelle Word sera dans la liste des mots soit encore aléatoire, et il peut y avoir pas un mot ultra-court sélectionné.)
- Ceci est mélangé avec une restriction de mot de passe distinct, ce qui signifie que l'attaquant a deux vecteurs pour tenter de se fissurer. L'utilisateur aurait pu sélectionner un mot de passe répondant aux exigences "traditionnelles" ou un mot de passe répondant aux exigences "XKCD".
Premièrement, il n'existe pas de concept tel qu'un mot de passe cryptographiquement sécurisé. Le but d'un mot de passe est d'être difficile à deviner pour un attaquant et sa difficulté dépend de la façon dont le mot de passe est utilisé: si le compte est verrouillé après trois tentatives infructueuses, le mot de passe peut être plus faible que lorsqu'un attaquant peut essayer un nombre illimité de mots de passe ou lorsque l'attaquant a accès aux mots de passe hachés.
Dans votre cas, vous créez un mot de passe en choisissant au hasard 5 mots dans un ensemble de 10 000 mots. En supposant que l'attaquant connaisse votre dictionnaire (ce qui n'est pas improbable car votre exigence est facile à retenir des mots) et la façon dont le mot de passe est construit à partir du dictionnaire, cela signifie qu'il existe (10 ^ 4) ^ 5 = 10 ^ 20 variantes. Cela revient à deviner 20 chiffres ou un mot de passe avec 12..13 caractères alphanumériques mixtes aléatoires. Ces mots de passe sont généralement considérés comme suffisamment sécurisés pour la plupart des applications.
En ce qui concerne le stockage du mot de passe: n'inventez pas votre propre méthode mais utilisez des méthodes éprouvées. Pour plus de détails, voir Comment hacher en toute sécurité les mots de passe? Dans la forme actuelle, je considérerais la méthode choisie comme faible car vous n'utilisez que 100 itérations avec une fonction de hachage conçue pour être rapide. Juste pour comparaison: PBKDF2 recommandait déjà au moins 1000 itérations en 2000 et LastPass a utilisé 100.000 itérations pour le hachage côté serveur en 2011. Heureusement, vous compensez le stockage de mot de passe plus faible en ayant des mots de passe plus complexes.
Il me semble que vos calculs sont corrects. Même si, veuillez considérer les faiblesses suivantes:
- Un attaquant peut et va s'inscrire à votre service avec plusieurs (a [~ # ~] beaucoup [~ # ~] de) comptes. À partir de là, il est trivial de créer une liste Word proche de l'original. Supposons donc que l'attaquant connaît la liste des mots.
- L'attaquant testera également vos limitations de longueur de mot de passe. Comme décrit ici , une longueur minimale de mot de passe de 12 caractères est une bonne indication pour un attaquant que des mots de dictionnaire consécutifs seront utilisés, réduisant ainsi l'espace de recherche.
- La liste de mots réelle fait également la différence. Envisagez un scénario dans lequel votre liste de mots se compose d'un nombre de mots de plus de 8 caractères et la longueur maximale de votre mot de passe est, disons 30. Cela signifie que l'attaquant peut supposer en toute sécurité qu'aucun mot de passe ne sera construit avec 4 mots consécutifs de 8 caractères. De même, de nombreuses hypothèses peuvent exister en fonction de votre choix de liste de mots. Donc, une autre considération que je pense que vous avez manquée est l'entropie de la longueur des mots.
- Enfin, le fait que vous fournissiez à vos clients un générateur de mot de passe sécurisé et facile à retenir signifie qu'ils l'utiliseront . Ainsi, l'attaquant peut également supposer en toute sécurité que tous, sauf les plus avertis en matière de sécurité, utiliseront votre liste de mots et votre générateur de mots de passe.
Malgré tout cela, je pense que ce que vous proposez est sûr. Même en considérant tout ce qui précède, l'espace de recherche résultant est toujours énorme.
Ce sont tous les problèmes/hypothèses que j'ai trouvés dans votre description qui peut-être diminuer la sécurité de votre générateur de mot de passe. Pour votre considération.
S'appuyant sur la réponse de MiaoHatola:
Par le premier point de MiaoHatola, votre attaquant pourrait réduire la liste et connaître les deux dictionnaires (l'un avec des mots courts et l'autre avec des mots de 5 lettres). Vous avez dit que votre courte liste de mots contenait 994 entrées. Ils ont 1/994 chance d'obtenir le court mot du premier coup. Supposons maintenant que vous utilisiez une liste de 10 000 mots communs de 5 lettres. Ces fractions s'appliquent:
1/994 * 1/10000 * 1/9999 * 1/9998 * 1/9997
Ce problème illustre les chances combinées de tout deviner du premier coup, en supposant qu'ils connaissent vos listes de mots.
C'est une chance sur 9 934 037 100 000 000 000 de deviner juste les mots, pas l'ordre des mots. Facteur dans l'ordre, et vous obtenez un nombre assez élevé. Ma calculatrice ne compte pas si haut.
Ce nombre n'inclut pas la possibilité de ce que MiaoHatola a mentionné dans son troisième point parce que vous avez dit que vous n'aviez pas de longueur maximale. Une dernière chose:
Au lieu de choisir au hasard seulement 5 mots à chaque fois, pourquoi ne pas randomiser ce nombre aussi? Ajoutez de temps à autre un mot de 7 lettres supplémentaires. Peut-être inclure un nombre à 2 chiffres à la fin. Essayez de faire deviner l'attaquant. Cela augmente considérablement votre sécurité. À ce stade, vous pouvez laisser les mots de passe hachés sans surveillance, car la quantité de possibilités est écrasante. Donc, pour répondre à votre question, oui. Cela augmente la sécurité. Par beaucoup.
Vous ne pouvez pas baser l'unicité sur 27 caractères car les caractères ne sont pas aléatoires.
Si vous avez 10 000 mots et utilisez 5 mots, 10 ^ 20 mots de passe (ou expressions) uniques
100 000 000 000 000 000 000 000
Est-ce assez unique pour déjouer une attaque par force brute
À 100 millisecondes, c'est plus de 30 000 ans
Mais le coût est que les utilisateurs entrent 27 caractères. Je ne veux pas entrer 27 caractères. Je vais probablement le saisir mal 1/2 fois et je devrai rentrer. 5 mots dans un ordre aléatoire ne seront pas faciles à mémoriser.
Considérez 6 caractères de A-Z, a-z, 0-9 et _
Soit 62 523 502 209 uniques
En tant qu'utilisateur, je préfère mémoriser et saisir 6
Je ne pense pas que 5 mots aléatoires écrits soient un bon moyen de masquer un mot de passe. Surtout si les gens savent que votre application le fait.