Politique basée sur les caractères spécifiques pour les mots de passe

Woodstock

2020-06-02 17:26:23 UTC

view on stackexchange narkive permalink

Je me demande s'il serait plus clair de déclarer une exigence à l'échelle de l'entreprise en ce qui concerne l'entropie théorique des mots de passe, plutôt que l'habituel "au moins une grande lettre, et une petite dernière, et un caractère spécial ..."

Ainsi, si nous ciblons un niveau d'entropie raisonnable dont les humains doivent se souvenir, disons 60 bits , puis calculons l'entropie.

Cela peut être calculé dynamiquement et localement et donnez des commentaires aux utilisateurs si nécessaire.

N'est-ce pas une meilleure façon, indépendante de la langue / région, de définir une politique de mot de passe?

Le seul problème est de faire comprendre cela à la personne moyenne.

Comment définissez-vous «mieux»?

Cela dépend du niveau de sécurité que vous souhaitez atteindre. Le simple fait de regarder l'entropie permet également des mots de passe courants tels que: 'Password1234' (50,8 bits) et 'MyPassword101' (58,7 bits).

@roy.stultiens Non, ce n'est pas le cas, car les * mots de passe * n'ont pas d'entropie.* Les méthodes de génération de mot de passe * ont une entropie, et toute méthode de génération avec plus de 50 bits est extrêmement peu susceptible de produire ces mots de passe.Si une méthode de génération a 50 bits d'entropie, cela signifie (en première approximation) qu'il y a au moins 2 ^ 50 mots de passe parmi lesquels elle aurait pu être sélectionnée.

@Ray, généralement le pirate ne connaît pas la méthode de génération, auquel cas l'entropie par rapport à la méthode de craquage, essentiellement la probabilité qu'ils essaient ce mot de passe, est plus intéressante.Bien sûr, étant donné que toute méthode de craquage essaiera probablement ces deux exemples dans les mille premiers environ, leur entropie est de 8 bits à peu près.

@JanHudec Bien que le pirate ne connaisse pas la méthode de génération, il prend une estimation raisonnable, ce qui conduit à des mots de passe comme "12345" essayés tôt et ": C

@JensSchauder, bien sûr;mais si vous trouvez des mots faciles à retenir pour vous pour une raison spécifique, mais qui ne sont pas des mots courants, alors un attaquant qui ne connaît pas la méthode ne les devinera toujours pas même si la méthode utilisée pour les générerune entropie très faible.Un attaquant ciblé peut bien sûr les apprendre d'une manière ou d'une autre et vous êtes alors en difficulté.

@schroeder * Le seul problème est de le faire comprendre à la personne moyenne. * De nos jours, de nombreuses interfaces ont une barre de mise à jour dynamique qui mesure la "force" de mon nouveau mot de passe pendant que je le saisis.Je pense que l'utilisateur moyen peut très bien comprendre ce type d'interface utilisateur.

@FedericoPoloni c'est une interface utilisateur, pas une politique

@schroeder La politique est "votre mot de passe est acceptable lorsque la barre atteint" fort "", et je pense que c'est tout ce que l'utilisateur final doit savoir.

Cinq réponses:

Conor Mancone

2020-06-02 17:36:56 UTC

view on stackexchange narkive permalink

Le problème fondamental est que l'entropie ne peut être estimée qu'à partir du mot de passe lui-même, et cette estimation peut être très erronée. L'entropie est déterminée par la méthode de génération de mot de passe. Vous ne pouvez pas mesurer l'entropie de la méthode à partir d'un seul mot de passe.

Regardons un exemple pratique. Je trouve qu'il est plus facile de mémoriser des mots de passe très longs générés à partir d'un petit espace de mot de passe, donc je vais utiliser uniquement des chiffres et le rendre très long. Votre algorithme regarde mon mot de passe, voit qu'il ne contient que des chiffres (c'est-à-dire que la taille du jeu de caractères est de 10) et qu'il comporte 20 caractères. Cela lui donne une entropie de:

log2 (10 ^ 20) = 66.4

Il réussit votre test! Mais arrêtons-nous et regardons le mot de passe:

01234567890123456789

Hmmm ... il s'avère que l'entropie réelle est jolie beaucoup de zéro.

Je pourrais être beaucoup plus technique mais dans ce cas, je pense qu'il vaut mieux garder la réponse simple. Je pense que cet exemple devrait fournir une réponse suffisante à votre question.

merci, voté!J'oblige les gens à choisir un mot de passe aléatoire, mais je reconnais que c'est une demande pour l'utilisateur moyen.

Si vous le demandez, vous pourriez peut-être aussi bien faire en sorte que votre système choisisse le mot de passe aléatoire pour eux.Si vous faites cela, vous contrôlerez bien sûr la quantité d'entropie qui y entre.

J'ai trouvé qu'une bonne option est d'utiliser un gestionnaire de mots de passe tel que KeePass et de le laisser générer des mots de passe (et les stocker, bien sûr.) En utilisant le stockage en nuage (mon propre serveur, base de données de mots de passe cryptés), il est possible d'accéder aux mots de passe de n'importe oùet faites-les entrer automatiquement dans les formulaires de connexion si nécessaire.

En fait, l'entropie est déterminée par la méthode qui * sera utilisée pour la fissurer *, qui peut ou non être liée à celle utilisée pour la générer.

@JanHudec malheureusement pas vrai.L'entropie est intrinsèque à la méthode de génération de mot de passe.Un nombre à 4 chiffres a 9999 possibilités - c'est l'entropie.Si un attaquant ne s'en rend pas compte et essaie de forcer brutalement les 4 chaînes alphanumériques de caractères, il fera beaucoup plus de travail pour lui-même, mais l'entropie du mot de passe n'a pas changé.Votre commentaire revient à dire que mon âge est déterminé par mon permis de conduire - alors que mon permis de conduire peut être un moyen de connaître mon âge, mon âge est toujours intrinsèque à moi.

@ConorMancone Mais ce qui * compte *, au moins la plupart du temps, c'est la méthode qui sera utilisée pour déchiffrer le mot de passe.Le temps nécessaire à un pirate de mot de passe pour trouver votre mot de passe dépend de votre mot de passe et du pirate, mais pas de la méthode utilisée pour générer le mot de passe.D'ailleurs, l'âge imprimé sur votre permis de conduire est ce qui détermine si vous pouvez ou non acheter de la bière.:) Ce que fait la méthode de génération de mot de passe, bien sûr, est de fournir une garantie pratique qu'un mot de passe prendra au moins telle ou telle tentative pour se fissurer.

@TannerSwett oui, je suis d'accord à 100%.Quand on parle d'entropie, il est logique de parler de la manière dont les mots de passe sont générés.Vous n'avez pas besoin de spécifier comment le mot de passe sera craqué pour décider de la quantité d'entropie dont il dispose.Dans une conversation sur le calcul du temps de craquage, il est évident que vous * avez * besoin de savoir comment il sera fissuré

Pour compliquer les choses, il est possible (bien que hautement improbable) pour un générateur à haute entropie de produire un mot de passe terrible comme votre exemple.

schroeder

2020-06-02 17:36:26 UTC

view on stackexchange narkive permalink

Les tests pour toute politique sont les suivants:

les gens le savent
les gens la comprennent
les gens savent s'ils s'y conforment
les gens savent comment s'y conformer

Votre approche est d'environ 2 sur 4 sur cette échelle pour l'utilisateur moyen.

La meilleure option est d'exiger des mots de passe générés aléatoirement. C'est facile à comprendre, facile à implémenter et facile à fournir des processus et des outils pour («il suffit d'utiliser ce gestionnaire de mots de passe»).

Avec votre approche, vous essayez essentiellement d'amener les gens à devenir leur propre générateur aléatoire. Cela entraînera de nombreux essais et erreurs lorsque les gens essaieront de déterminer quel mot de passe passera le test. Cela entraînera de la frustration et de la confusion.

Mais cela suppose que vous écrivez une politique pour l'utilisateur moyen et que votre calcul d'entropie est valide (ce qui semble hors du sujet de votre question en ce moment, et j'ai de sérieuses réserves à ce sujet).

Bon point sur la façon dont cela demande essentiellement aux gens de demander comme des générateurs de nombres aléatoires.L'une (des nombreuses) raisons pour lesquelles les gens sont si mauvais en mots de passe est que nous sommes, par nature, de terribles générateurs de nombres aléatoires.

Il n'est pas toujours possible (ou plutôt pratique) d'utiliser des mots de passe aléatoires.Un exemple est la connexion Windows.Dans ce cas, une phrase de passe de type xkcd est préférable.Sinon oui - gestionnaires de mots de passe.

@WoJ "aléatoire" ne signifie pas nécessairement "chaîne aléatoire".«Random 3 words» est une norme du NCSC du Royaume-Uni.

@WoJ Et pour donner suite au commentaire de schroeder, la méthode xkcd que vous mentionnez suppose spécifiquement que les mots sont tous sélectionnés uniformément au hasard.L'entropie est plus basse si vous utilisez des phrases de passe qui signifient quelque chose.

@schroeder: oui, mon commentaire était dans le contexte de * La meilleure option est d'exiger des mots de passe générés aléatoirement.(...) ("il suffit d'utiliser ce gestionnaire de mots de passe") * Le résultat d'un gestionnaire de mots de passe ne sera pas une phrase de passe basée sur des mots (et maintenant que j'y pense - c'est quelque chose qui manque dans le (s) un (s))J'ai utilisé).

@Ray: oui c'est bien plus bas si la phrase de passe signifie quelque chose (encore plus quand c'est "quelque chose de bien connu").Cela n'a pas à signifier quelque chose, même lorsque les mots sont connectés, c'est un problème ("bleu rouge jaune vert").Cela dit, il est peut-être bien meilleur que "password1234".Le ** vrai ** problème est de savoir comment définir correctement votre "bien plus bas" et mon "bien mieux" dans le contexte réel de l'utilisation de l'OP (n'importe qui d'autre)

@WoJ: [Bitwarden] (https://bitwarden.com/) a un générateur de phrase de passe de style xkcd.Par exemple, il vient de générer ceci pour moi: "Decibel-Basin-Resurface-Ideally-Shelve1".(Ce n'est pas une approbation de Bitwarden, il s'est avéré que c'était le seul gestionnaire de mots de passe qui avait des clients pour tous les systèmes d'exploitation et plugins pour tous les navigateurs dont j'avais besoin au moment où j'ai pris la décision. Le compromis qu'il utilise son propre service de synchronisation cloudau lieu de me permettre de choisir était un compromis que j'étais prêt à faire à l'époque.)

@JörgWMittag: J'utilise Bitwarden (et je l'héberge moi-même également) et j'étais sur le point d'ouvrir une demande de fonctionnalité pour cela: - |- Je n'ai jamais réalisé qu'il y avait autre chose que "mot de passe" dans les choix.Merci beaucoup d'avoir ouvert les yeux (c'est vraiment un excellent produit BTW)

Ray

2020-06-03 19:33:44 UTC

view on stackexchange narkive permalink

Une chose clé à comprendre lors de la sélection d'une politique de mot de passe (ou d'un mot de passe) est que l'entropie n'est pas une propriété du mot de passe. C'est une propriété de la méthode utilisée pour le générer. Plus généralement, il s'agit d'une propriété des distributions de probabilités qui nous indique à peu près la quantité d'informations supplémentaires dont vous auriez besoin pour identifier de manière unique un élément tiré de cette distribution si vous connaissez la distribution. Je vais un peu plus en détail dans une réponse précédente si vous êtes intéressé, mais pour les mots de passe, cela signifie grosso modo que s'il y a 2 ^ n mots de passe que vous pourrait avoir généré, vous avez une entropie de n.

Si les utilisateurs génèrent leurs propres mots de passe, vous ne pouvez pas savoir quelle méthode ils ont utilisée. Vous ne pouvez définir que des politiques qui rendent plus probable que les utilisateurs sélectionnent une méthode qui a une entropie élevée. Ce faisant, vous devez garder à l'esprit que les utilisateurs trouveront généralement le moyen le plus paresseux de se conformer à une politique, c'est pourquoi exiger qu'un mot de passe doit contenir des lettres majuscules et des chiffres revient à exiger que la première lettre soit en majuscule et que il y a un seul chiffre à la fin.

La meilleure politique de mot de passe que j'ai vue est celle de Stanford, ce qui rend les exigences relatives aux caractères spéciaux moins onéreuses plus le mot de passe est long, pour encourager l'utilisation de longues phrases de passe au lieu de Password1 $ . Si le mot de passe contient moins de 12 caractères, il requiert tous les types de caractères. Cette restriction est assouplie à mesure que la longueur augmente, et une fois que le mot de passe contient au moins 20 caractères, il n'y a aucune restriction supplémentaire. (Il n'y a pas non plus de limite supérieure pour la longueur du mot de passe. Rien n'est plus ennuyeux qu'une politique de mot de passe qui m'oblige à utiliser des mots de passe courts au nom de la sécurité.) Il suggère ensuite de sélectionner au hasard 4 mots comme moyen d'obtenir des mots de passe aussi longs, qui est une méthode de génération de mot de passe avec une entropie élevée.

Dans le cadre de cette politique, la bonne approche est également la plus paresseuse, ce qui signifie que les utilisateurs peuvent réellement le faire.

@Woodstock Vous pourriez également trouver [DiceWare] (https://theworld.com/~reinhold/diceware.html) intéressant.J'utilise personnellement leur méthode mais avec certaines des listes de mots EFF (liées au bas de cette page)

J'aime cette approche de Stanford.Quelqu'un sait-il comment il le met en œuvre?Je sais comment définir des longueurs minimales et des exigences de complexité (essentiellement simplement complexes ou non complexes) dans Active Directory pour les comptes Windows, mais je ne sais pas comment je procéderais pour implémenter les exigences échelonnées.

Je pense que la présentation de cette politique de mot de passe à un utilisateur normal conduirait à une adoption intrinsèquement dangereuse de celle-ci par les utilisateurs.L'exemple de mot de passe se compose uniquement de noms et il est peu probable qu'un utilisateur moyen choisisse entre plus de 500 noms différents lorsqu'il en est demandé.Vous vous retrouvez donc avec pas plus de 60 milliards de mots de passe différents, ce qui est encore assez facile à forcer une fois que les hachages sont divulgués.Et je pense que les 500 noms sont encore énormément exagérés parce qu'un utilisateur normal, par exemple, regarderait simplement autour de vous pour trouver des noms à utiliser.

@SpaceTrucker: Eh bien, 60 milliards représentent environ 37 bits d'entropie (en supposant que chaque PW est également probable).Ce n'est pas si mal pour un mot de passe généré par l'utilisateur ...

@DougDeden Bien que je ne sois pas une personne Windows, je doute que vous puissiez le faire dans un tel cas.Ces choses sont plus faciles lorsque vous avez un contrôle total sur le processus de connexion.

@SpaceTrucker Cela n'a pas vraiment d'importance.Vous imaginez un attaquant qui dit: "Je parie que cette personne vient de choisir des noms. Permettez-moi de charger une liste de noms communs et de les utiliser pour construire ma liste bruteforce".Bien qu'une telle chose puisse se produire si ce style de mots de passe devient courant, ce n'est pas le cas actuellement, donc un tel mot de passe serait absolument à l'abri du type d'attaques qui constituent une menace pour la plupart des utilisateurs.

@ConorMancone Au moins pour les comptes liés à l'université de Stanford, je suppose qu'il se peut déjà que ces types de mots de passe soient maintenant assez courants.

@SpaceTrucker Comme GalacticCowboy l'a mentionné, Diceware fonctionne bien en conjonction avec cette politique pour résoudre le problème des «500 noms».Le dictionnaire peut être lié à sur la page de politique.Quatre mots Diceware donnent 51,7 bits d'entropie.

@SpaceTrucker Je suis d'accord avec vous.Il est important de choisir au hasard des mots dans un grand dictionnaire.Si les utilisateurs choisissent des mots qui leur viennent à l'esprit, le dictionnaire sera réduit à quelques mots préférés ou objets courants.Quelque chose comme "fenêtre lampe de bureau café".Ce n'est probablement pas pire que la plupart des mots de passe classiques choisis par les utilisateurs, mais c'est loin d'être l'entropie du logiciel de dé.

@ConorMancone S'il existe apparemment des infographies qui recommandent de choisir 4 noms comme meilleure pratique, il n'est pas déraisonnable pour un attaquant de penser que les utilisateurs feront exactement cela.

@kapex Plus précisément, peu importe si l'attaquant sait quelle méthode vous utilisez.[L'ennemi connaît le système] (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).Un bon mot de passe sera fort car il y a des milliards de milliards de possibilités à parcourir même si vous connaissez la méthode exacte utilisée.* Mes * mots de passe sont généralement 4 mots sélectionnés uniformément dans le fichier du dictionnaire Unix, tous en minuscules, séparés par des tirets.Si un système insiste sur les majuscules et les chiffres, la première lettre est en majuscule et il y a un 3 à la fin.Connaître ces informations ne vous permettra pas de les deviner.

@Ray basé sur le fait que votre mot de passe est clairement `Leonel's-Lauri-Jacobin-Lucretius`

basé sur cette ligne de code la plus piratée (note: pas pour une utilisation en production, lol!) `for i in {1..4};do sed -n "$ (($ RANDOM% 100000)) p" / usr / share / dict / words;fait |tr '\ n' '-'`

@ConorMancone Leonel's-lauri-jacobin-lucretius _ ** 3 ** _.

@Ray lol!Vous avez officiellement gagné Internet pour la journée.

Dave

2020-06-03 23:48:30 UTC

view on stackexchange narkive permalink

Je l'ai fait une fois avec quelques centaines d'utilisateurs.

J'ai estimé l'entropie en fonction de la taille approximative de l'alphabet qu'ils utilisaient, où les mots courants du dictionnaire (tirés d'un dictionnaire anglais) comptaient pour un "lettre" chacun, et les mots inconnus ont été divisés en alpha inférieur, alpha supérieur, nombres, symboles, espaces blancs, etc. Il y avait quelques autres modèles communs qu'il identifierait dont je n'entrerai pas dans les détails car ce n'est pas pertinent.

Si l'entropie calculée était trop faible, le mot de passe était rejeté et l'utilisateur recevait des conseils pour l'améliorer. Il y avait certainement place à amélioration mais cela fonctionnait très bien pour filtrer les mots de passe clairement faibles.

Le problème était que les utilisateurs détestaient cela car il était difficile à comprendre (en particulier, il était difficile pour eux de faire un mot de passe faible assez fort pour être utilisé sans le rendre vraiment long).

Au lieu de cela, ces jours-ci, je recommanderais d'appliquer seulement une longueur minimale , mais de vérifier les mots de passe des utilisateurs par rapport à un base de données des mots de passe connus (par exemple, https://haveibeenpwned.com/Passwords) et avertir l'utilisateur si son mot de passe est trouvé.

C'est tentant de bloquer les mots de passe dont vous savez qu'ils sont mauvais, mais si un utilisateur n'écoute pas un avertissement, c'est parce qu'il ne se soucie pas du compte de toute façon. Si vous forcez ces utilisateurs à choisir un mot de passe plus difficile, ils risquent de le compromettre d'une autre manière (par exemple en l'écrivant sur un post-it sur leur moniteur).

Enfin, s'il vous plaît considérez si vous avez même besoin de mots de passe. Nous sommes loin de l'époque où chaque service Web a son propre identifiant. Il existe un grand nombre de services d'authentification unique auxquels vous pouvez intégrer pour décharger la gestion des connexions et faciliter les choses pour vos utilisateurs (tout en offrant une MFA, etc.), et pour les choses plus sécurisées, l'utilisation de certificats est une meilleure sécurité. de toute façon (le support du navigateur pour MTLS est plutôt bon maintenant!)

Tom

2020-06-04 14:31:17 UTC

view on stackexchange narkive permalink

plutôt que l'habituel "au moins une grande lettre, et une petite dernière, et un caractère spécial ..."

Toute politique contenant ces exigences en 2020 est enfreinte et doit être révoqué. (*)

Les principales choses que les utilisateurs réguliers doivent savoir sur les mots de passe sont:

il doit être long (10 à 12 caractères recommandés)
il ne doit pas être devinable (pas "mot de passe" ou "1234567890" ou votre nom, anniversaire, etc.)

au niveau informatique, vous devrait avoir une liste noire (les 1000 mots de passe les plus courants ou autres).

(*) les règles de complexité sont incorrectes . Dans presque tous les cas, ils rendent les mots de passe plus faciles à compromettre. Ne les utilisez pas. Sérieusement, non. Ce ne sont plus les années 80.

@Mark Je veux dire de compter chaque modèle comme équivalent à 1 caractère de long.Je republierai mon commentaire pour clarifier cela.

Au lieu d'une liste noire de 1000 mots de passe, mieux vaut avoir une liste grise de 1000 sous-modèles, où chaque partie de votre mot de passe correspondant à "1234", "9999", "abcd", "qwerty", "pass", "word", ... serane comptez que pour une longueur de 1.

@Cœur ce n'est pas une liste noire aléatoire, ce sont "les 1000 mots de passe les plus courants".La raison pour laquelle je recommande définitivement de les mettre sur liste noire est que les gens les utilisent réellement, c'est pourquoi ils sont sur cette liste.Et les outils de force brute utilisent ces listes.Vous ne voulez certainement pas que quelqu'un ait un mot de passe que toute attaque automatisée essaiera certainement, et dès le début.

ⓘ

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 4.0 sous laquelle il est distribué.