Question:
Qu'est-ce qui est pire pour la force du mot de passe, une politique de mot de passe médiocre ou aucune politique de mot de passe du tout?
Bob Ortiz
2016-07-26 18:56:15 UTC
view on stackexchange narkive permalink

Récemment, j'ai vu la capture d'écran suivante sur Twitter, décrivant une politique de mot de passe manifestement terrible:

bad password policy

Je me demande ce qui est pire pour la force du mot de passe. Vous n'avez pas du tout de politique de mot de passe ou une mauvaise politique de mot de passe (comme décrit dans la capture d'écran)?

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/43084/discussion-on-question-by-kevin-morssink-what-is-worse-for-password-strength-a).
Dix réponses:
Josef says Reinstate Monica
2016-07-26 19:42:30 UTC
view on stackexchange narkive permalink

La question est: pire pour quoi?

Avec la politique que vous avez publiée, les mots de passe possibles sont inférieurs à 64⁸ (~ 2,8 * 10¹⁴). En pratique, la plupart des mots de passe seront probablement [az] * 6 [0-9] [caractère spécial] (par exemple aabaab1!) Et des mots de passe similaires.

Tous les mots de passe possibles avec les mêmes caractères et une longueur inférieure à 8 sont juste 64⁷ + 64⁶ + 64⁵ + ... soit ~ 4,5 * 10¹². C'est beaucoup moins que les mots de passe de longueur 8, donc cela n'augmente pas beaucoup la sécurité pour leur permettre. (autoriser des mots de passe plus longs augmenterait évidemment beaucoup la sécurité)

Sans aucune politique, de nombreuses personnes utiliseront également de mauvais mots de passe, bien sûr. Mais un attaquant ne peut pas en être sûr. Certaines personnes utiliseront également de meilleurs mots de passe.

Sans aucune politique, un attaquant ne peut jamais être sûr de la difficulté de déchiffrer un mot de passe. Si vous me donnez une base de données de hachages de mots de passe, je pourrais essayer de la casser. Mais s'il n'y a pas de résultats, après un certain temps, je pourrais m'arrêter. Avec la politique en place, je peux être sûr qu'après 64 ^ 8 essais, j'ai tous les mots de passe.

Je dirais qu'une mauvaise politique de mot de passe est pire. Mais cela dépend du scénario d'attaque.

Avec un vidage des hachages de mots de passe, sans politique de mot de passe, il est très probablement plus facile de déchiffrer n'importe quel mot de passe, mais plus difficile de déchiffrer la plupart des mots de passe. Avec une mauvaise politique comme celle donnée , il est plus facile de déchiffrer tous les mots de passe, mais un peu plus difficile de déchiffrer le premier, très probablement.

Si vous vous inquiétez de la difficulté de déchiffrer votre propre mot de passe, sans aucune politique, vous pouvez utiliser un Mot de passe aléatoire de 20 caractères si vous le souhaitez. Avec la politique en place, vous êtes obligé d'utiliser un mot de passe non sécurisé. (en pratique, il est plus pertinent de savoir comment les mots de passe sont stockés et ainsi de suite, mais c'est hors de portée ici). Donc, en tant qu'utilisateur du site Web / service, une mauvaise politique de mot de passe est bien pire.

Si vous la regardez d'un point de vue organisationnel, une mauvaise politique de mot de passe est bien pire que rien.

Aucune politique de mot de passe signifie, probablement que personne n'y a pensé (pas très bien qu'ils ne pensent pas à la sécurité, mais ok ...)

Mais une mauvaise politique de mot de passe signifie: Quelqu'un y a pensé et a trouvé cette merde. Cela signifie qu'ils n'ont probablement aucune idée de la sécurité.

En fin de compte, si vous pouvez implémenter une politique de mauvais mot de passe, vous pouvez également en implémenter une bonne pour qu'il n'y ait aucune excuse pour une politique de mauvais mot de passe. Le simple fait de changer la politique en "Un mot de passe doit contenir au moins 8 caractères" augmenterait beaucoup la sécurité et ce n'est pas difficile à faire.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/43083/discussion-on-answer-by-josef-what-is-worse-for-password-strength-a-poor-passwo).
Impossible d'afficher l'historique des discussions
Bryan Field
2016-07-26 20:30:43 UTC
view on stackexchange narkive permalink

Maintenant, je me demande ce qui est pire pour la force du mot de passe. Vous n'avez pas de politique de mot de passe du tout ou une politique de mot de passe médiocre comme dans l'image?

Les exigences de résistance du mot de passe que vous avez mentionnées font absolument plus de mal que de bien , en particulier le maximum length.

  1. Ils utilisent peut-être une très ancienne routine de hachage non sécurisée. (donc une longueur maximale)
  2. Dans certaines zones, cela prend en charge la commodité par rapport à la sécurité.
    (aucun espace n'est utile pour représenter un mot de passe en texte brut,
    insensible à la casse donc il y a pas d'appels de support de verrouillage des majuscules)
  3. D'autres éléments sont tout simplement stupides.

Ventilation détaillée

Votre mot de passe doit:

  • contenir exactement huit caractères

La seule fois où je peux voir cela comme une solution raisonnable, c'est lorsque le système exécute un ancien schéma de hachage qui tronque tous les caractères sauf les 8 premiers.

Par exemple, les mots de passe de compte utilisateur Solaris 10 utilisaient un tel schéma par défaut, donc les mots de passe tels que passwordSup @ rsecur☺ étaient tronqués au mot de passe !!! La valeur par défaut de Solaris 11 n'a pas cette lacune.

Dans ce cas

  1. Les développeurs devraient travailler sur la migration vers une meilleure routine de hachage qui prend en charge la longueur des mots de passe au-delà de 8.

  2. Jusqu'à ce qu'un tel correctif soit déployé, la longueur maximale est raisonnable.

Dans toute autre situation , ce serait certainement une chose stupide d'avoir une longueur maximale aussi courte.

  • Incluez au moins une lettre et un chiffre.

  • Incluez au moins un caractère spécial de l'ensemble suivant: ...

Ceux-ci sont indispensables étant donné leur courte longueur maximale. Je suis sûr que vous pouvez comprendre la nécessité d'utiliser de telles méthodes primitives pour augmenter l'entropie lorsqu'un mot de passe court est utilisé.

  • Remarque: le mot de passe n'est pas sensible à la casse.

Bien que cela puisse être pratique pour l'utilisateur (ne vous inquiétez pas du verrouillage des majuscules), cela n'est jamais recommandé car cela diminue toujours l'entropie du mot de passe. Dans ce cas, il est encore plus fortement déconseillé en raison de la présence d'une longueur maximale de 8 caractères.

Cela devrait être corrigé mais maintenant ce serait un problème pour eux car les utilisateurs existants sont déjà habitués à la configuration non sécurisée!

Ne contient aucun espace

La seule raison que je vois pour cela est s'ils présentent le mot de passe en texte brut . (c.-à-d. mot de passe oublié, ou recherche d'assistance technique) Selon la plupart des normes, la conception de logiciels est médiocre (non sécurisée).

Une meilleure politique consiste à interdire les recherches et à ne permettre que leur modification. En fait, il est fortement recommandé d'utiliser un hachage de mot de passe fort (lent) tel que BCrypt qui interdit par nature les recherches dans le cadre de sa conception principale.

  • Vous ne commencez pas par ? ou !

Très étrange, mais pas un tueur significatif de l'entropie de mot de passe.

  • Pas commencer par trois caractères identiques

Meh, je ne suis pas trop préoccupé par celui-ci, mais je me demande pourquoi ils ne regardent que le début. 3 caractères identiques / adjacents n'importe où dans un mot de passe de 8 caractères est plus faible qu'il ne pourrait l'être.

  • Le mot de passe doit être différent de vos 5 mots de passe précédents.

Il y a probablement une question dédiée à Security Stack Exchange pour ce sujet. C'est une pratique courante pour les services bancaires en ligne et certains autres systèmes d'authentification.

Je suppose que cela est également associé à un changement de mot de passe programmé obligatoire. Les résultats probables sont les suivants:

  • Les utilisateurs noteront leur mot de passe au lieu d'utiliser leur mémoire,
  • Ou bien, les utilisateurs choisiront un modèle simple.

Cependant, si le changement de mot de passe n'est pas obligatoire, le seul problème est

  • Il faut continuer à stocker la valeur de hachage des mots de passe inutilisés pour que la comparaison fonctionne.

et bien que ce ne soit pas un problème grave, il est mal vu.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/43362/discussion-on-answer-by-george-bailey-what-is-worse-for-password-strength-a-caca).
O'Niel
2016-07-26 19:51:07 UTC
view on stackexchange narkive permalink

Une mauvaise politique comme celle-ci est pire que rien.

Cette politique signifie que les personnes qui utilisent normalement '123' auront désormais un mot de passe un peu plus sécurisé, mais il est toujours faible. les personnes utilisant quelque chose comme 'fzFEZ # 5 $ 3rt4564ezezRTyht' (généré aléatoirement), ou simplement: 'cat j_umps over the brown paint wall412' (forte entropie), auront maintenant un mot de passe beaucoup plus faible.

Le les personnes utilisant des mots de passe faibles de toute façon seront piratées dans ce cas également (parce que cette politique restrictive et faible et que l'attaquant est capable de définir des règles d'attaque spécifiques). Mais les gens qui utilisent normalement des mots de passe forts le feront aussi.

En d'autres termes, c'est beaucoup moins sécurisé. Sans aucune politique, seules les personnes utilisant des mots de passe faibles sont vulnérables; maintenant tout le monde est vulnérable.

LvB
2016-07-26 19:50:02 UTC
view on stackexchange narkive permalink

à mon avis, n'en avoir aucun serait mieux Une liste de raisons est:

  • Ces politiques font que les gens ont tendance à y écrire des mots de passe et à les coller sur les moniteurs ou autres. (quelle sécurité un mot de passe fournit-il?)
  • Ces règles sont facilement déduites et (en utilisant ce type de boîtiers) même annoncées à tout intrus potentiel. (Par exemple, donnons à la personne que nous voulons garder à l'écart les `` règles '' de la façon dont sont nos mots de passe afin qu'ils n'aient qu'à faire un ensemble limité ...)
  • L'entropie d'un mot de passe s'améliore considérablement en les rendant plus long. 8 est de nos jours suffisamment trivial pour qu'une attaque puisse utiliser un appareil mobile pour forcer un mot de passe.
  • la règle consistant à mélanger les cas et à ne pas les vérifier suggère que le mot de passe est affiché sous forme de texte brut (même si le stockage est crypté, la plupart du temps, la clé de cryptage est stockée avec les données, ce qui signifie effectivement qu'elles sont stockées en texte clair).
  • Pour la plupart des applications, un schéma différent permettrait une sécurité beaucoup plus grande sans exigeant un mot de passe du tout, comme:
    • Authentification à 2 facteurs.
    • Authentification secondaire de l'appareil.
    • Authentification par carte à puce.

Ces politiques semblent avoir été conçues par quelqu'un qui ne comprend pas parfaitement l'impact des menaces sur un mot de passe sur votre système. au lieu de cela, ils cochent simplement «toutes les cases» pour une raison quelconque.

cela étant dit, il peut y avoir une vraie raison pour laquelle ils ont fait cela. certaines certifications et utilisations exigent que certaines d'entre elles soient mises en œuvre (pensez au secteur de la santé ou à une utilisation gouvernementale).

Si vous avez besoin de publier quelque chose sur votre moniteur: créez un mot de passe à partir de quelque chose de facile à retenir que vous seul connaissez et d'une séquence aléatoire.Publiez dans une séquence aléatoire sur votre moniteur.Les pirates à l'extérieur ne peuvent pas voir la note.À l'intérieur, j'espère que vous n'avez pas de pirates informatiques capables de comprendre votre partie facile à retenir.Ce n'est pas une bonne solution mais bien meilleure que votre mot de passe complet disponible pour vos collègues.
C'est un mauvais conseil.il vaut mieux NE JAMAIS noter les mots de passe.Et si vous les avez notées, ne les stockez PAS avec une machine sur laquelle elle est utilisée.(comme un post-it à l'écran).Il n'y a pas de différence entre un pirate informatique extérieur et un pirate informatique interne, et l'ingénierie sociale est le moyen préféré pour obtenir des mots de passe (car elle laisse peu de traces)
dandavis
2016-07-26 19:53:07 UTC
view on stackexchange narkive permalink

Rien du tout n'est meilleur que celui illustré, en particulier à cause de la limite de 8 caractères.

Les combinaisons de 8 caractères peuvent être testées en une seconde avec un GPU de la famille Titan et John the Ripper. Bien que toutes les politiques de mot de passe ne soient pas préjudiciables (la longueur minimale est bonne, un + caractère spécial force un alphabet de crack plus gros, pas de mots du dictionnaire, etc.), celle montrée est une blague qui n'est pas très drôle. En résumé, oui, c'est pire que rien, car cela ne permettra pas aux gestionnaires de mots de passe ou aux utilisateurs intelligents de mieux se protéger que la politique par défaut.

Les politiques ne devraient jamais arrêter les bons mots de passe, seulement les mauvais.

GPU de la famille Titan?Je doute que vous en ayez même besoin étant donné les nouveaux GPU 14 / 16nm de nos jours.Une Radeon RX 480 à 200 $ (avec 5,8 GFLOPS!) Brûlera probablement les mots de passe comme rien.
Exiger un caractère spécial ne force pas réellement un alphabet de crack plus grand: dans le monde réel, il y aura exactement un caractère spécial, et il viendra presque toujours à la fin du mot de passe (parfois il viendra au début).De plus, dans le monde réel, ce symbole sera généralement un '!', Le reste étant sélectionné à partir de "? @ # $% & *" - cela en fait * réduit * la taille de l'alphabet, car l'attaquant sait qu'il y aseulement huit options pour le caractère final.
David Richerby
2016-07-28 01:46:35 UTC
view on stackexchange narkive permalink

Qu'est-ce qui est pire pour la force du mot de passe, une mauvaise politique de mot de passe ou aucune politique de mot de passe du tout?

Cela dépend de la mauvaise politique de mot de passe.

  • "Votre mot de passe doit être 'letmein'" est une mauvaise politique de mot de passe qui est certainement pire que de n'avoir aucune politique du tout, car elle empêche quiconque d'avoir un bon mot de passe.

  • "Votre mot de passe doit comporter au moins deux caractères" est une mauvaise politique de mot de passe qui est certainement meilleure que de n'avoir aucune politique du tout, car elle permet à quiconque d'utiliser un bon mot de passe et empêche certains mots de passe erronés.

Evan Steinbrenner
2016-07-30 00:34:37 UTC
view on stackexchange narkive permalink

Il existe déjà un certain nombre de bonnes réponses, mais j'aime toujours voir cela sous un angle légèrement différent. Lorsque vous envisagez comment quelque chose affectera les tentatives de piratage d'un mot de passe, vous devez regarder comment ils essaieront de le faire. Fondamentalement, cela se résume à deux méthodes. La force brute et les devinettes «intelligentes», regardons donc ces deux-là.

1) Force brutale.

C'est exactement ce à quoi cela ressemble. Ils essaient tous les mots de passe possibles. C'est le classique en essayant chaque broche de 0000 à 9999 sur un verrou numérique à 4 chiffres. Les facteurs clés ici sont le nombre de mots de passe possibles et le temps qu'il faut pour essayer chaque hypothèse. Ici, la règle de mot de passe pourrait être excellente et éliminer complètement la force brute en tant qu'option viable en raison de l'exigence de 8 chiffres. Cela peut également être complètement catastrophique si un hachage suffisamment faible est utilisé et peut garantir que chaque mot de passe possible est craqué dans un délai raisonnable à un attaquant disposant de suffisamment de ressources.

Étant donné les règles dans ce cas, il semble suggèrent fortement quelque chose d'assez ancien sur le back-end, il est tout à fait possible, sinon probable, que le mot de passe soit haché avec quelque chose d'assez faible comme MD5 ou SHA1 et probablement pas salé et les règles pourraient être catastrophiques. Principalement la longueur mais également ne pas être sensible à la casse, ce qui réduit les caractères possibles d'environ 30%. Ils ont actuellement 26 caractères + 10 chiffres + 28 symboles pour 64 caractères différents dans un mot de passe. Ils auraient 90 caractères s'ils étaient sensibles à la casse.

Sur la base de quelques recherches rapides, il semble que si nous supposons un attaquant avec une quantité raisonnable de ressources et qu'il utilise l'un de ces hachages faibles, il semble très il est probable que les règles soient en effet catastrophiques et si elles ne le sont pas maintenant, elles risquent certainement de devenir catastrophiques dans un proche avenir, car la puissance de calcul augmente le taux de craquage. Un mot de passe de plus de 8 caractères peut être requis pour être sécurisé, mais ils ne le permettent pas réellement.

Est-il possible de forcer brutalement les 8 mots de passe de caractères dans une attaque hors ligne?

2) Devinette "intelligente"

À un moment donné, la méthode de la force brute devient peu pratique, il faudrait des mois pour tester tous les mots de passe, ou impossible, il faudrait des millénaires pour tous les tester, et les devinettes «intelligentes» prennent le dessus. C'est là que vous voyez des attaques de dictionnaire, soit des mots littéraux du dictionnaire, soit des listes de mots de passe précédemment utilisés, et des attaques basées sur des règles. Les attaques basées sur des règles prennent le dictionnaire et commencent à ajouter ou à modifier des éléments pour créer différentes variantes de ces mots de passe. Ajout d'un nombre et d'un caractère spécial à la fin d'un mot de six lettres pour obtenir un mot de passe à 8 chiffres qui répond aux exigences de mot de passe. Rendre le mot de passe "leet" en transformant le mot de passe en p @ ssw0rd qui serait un mot de passe valide mais rapidement craqué dans ce système, etc. Ces règles peuvent être presque tout ce que vous pouvez imaginer et qui vous semble logique et évolue constamment à mesure que nous en apprenons plus. sur la façon dont les gens choisissent généralement leurs mots de passe en fonction des fuites passées.

En supposant que le piratage arrive à ce point, les règles de mot de passe qu'ils ont données finiraient par être incorporées dans les règles utilisées par l'attaquant pour générer son éventuel mot de passe. Ici, leurs règles ne sont pas aussi catastrophiques mais conduiraient toujours à des mots de passe beaucoup moins valides, ce qui accélérerait le craquage. Cela conduirait également probablement à des mots de passe très prévisibles avec des symboles / nombres ajoutés au début / à la fin du mot de passe ou dans le cadre d'une substitution très prévisible.

Peter Green
2016-07-27 17:39:07 UTC
view on stackexchange narkive permalink

Si les utilisateurs choisissaient des mots de passe au hasard, les politiques de mot de passe aggraveraient la sécurité en limitant le choix des mots de passe possibles, mais les utilisateurs ne choisissent pas les mots de passe au hasard. Le but d'une bonne politique de mot de passe devrait être de pousser un utilisateur à faire plus de choix et donc à choisir un mot de passe plus fort sans limiter indûment l'espace des mots de passe.

Cette politique a de bons et de mauvais aspects.

contenir exactement 8 caractères

Une longueur minimale est bonne, une longueur maximale est mauvaise.

Incluez au moins une lettre et au moins un chiffre.

C'est bien, cela pousse les utilisateurs à choisir à la fois un composant basé sur une lettre et un nombre composant basé sur.

Le mot de passe n'est pas sensible à la casse.

Cela réduit considérablement la taille du mot de passe défini. D'un autre côté, la plupart des gens n'utilisent pas de majuscules à moins d'être forcés de toute façon et lorsqu'ils les utilisent, ils ont tendance à le faire de manière prévisible.

Incluez au moins un caractère spécial

Encore une fois bien, cela pousse le créateur du mot de passe à faire un autre choix.

Espaces interdits et règles sur? et !

Je doute que cela fasse une grande différence.

caractères répétés interdits au début

Probablement une bonne chose, signifie l'utilisateur ne peut pas simplement remplir le mot de passe avec des répétitions d'une seule lettre.

Dans l'ensemble, je dirais que si vous avez des utilisateurs ignorants, cette politique est probablement meilleure que rien, mais si vos utilisateurs ont un indice sur les mots de passe décents, il fera probablement plus de mal que de bien.

L'espace/?!la règle n'est pas mauvaise en soi, mais ses implications sont terrifiantes.Cela suggère fortement qu'ils font quelque chose avec le mot de passe en clair au sein de l'application que certains caractères pourraient casser.Cela me fait moins peur que "ne doit pas contenir d'apostrophe", mais pas de beaucoup.L'insensibilité à la casse et la longueur maximale peuvent également suggérer un stockage en clair.
"une longueur maximale est mauvaise" -> "une longueur maximale est mauvaise"?
MikeP
2016-07-28 08:29:50 UTC
view on stackexchange narkive permalink

Je vais suivre une voie différente de toutes les autres réponses jusqu'à présent ... et dire qu'à un moment donné, cela n'a pas d'importance. L'algorithme importe BEAUCOUP plus que les règles de mot de passe.
Par exemple, quelqu'un pourrait utiliser ROT13, terrible, oui.
Ou, mieux vaut utiliser MD5.
Ou, mieux encore, SHA-1.
Peut-être qu'ils ajoutent du sel.
Utilisez peut-être crypt ().
Ajoutez peut-être du poivre.
Pourtant, un GPGUP peut brûler des milliards de hachages de mots de passe en une seconde. Alors, quoi d'autre?
SHA-2-512 avec 128 bits de sel. Encore mieux, GPGPU peut faire beaucoup de ces choses.
Changez pour bcrypt. Bien mieux. Maintenant, nous avons dépassé le point où un seul GPGPU peut tout simplement les graver tous rapidement.
Passez à PBKDF2, avec plein de sel et de poivre et 10 000 tours.
À lire, et maintenant un mot de passe très court est «incassable» car l'algorithme est si lent.

Voici un tableau qui pourrait vous aider à l'expliquer:

  Tries / secNTLM 350,000,000,000 MD5 180,000,000,000 SHA1 63,000,000,000 SHA512Crypt 364,000 Bcrypt 71,000  

Donc, un mot de passe merdique haché avec bcrypt vaut mieux qu'un excellent haché avec MD5.

Verbal Kint
2016-08-03 19:02:10 UTC
view on stackexchange narkive permalink

Cela dépend vraiment de l'utilisateur final. D'après moi, si vous en tant qu'entreprise / site Web n'êtes pas responsable si le compte de quelqu'un est compromis, il est préférable de renoncer à une politique de mot de passe formelle, au moins restrictive.

J'ai toujours été d'avis que l'utilisateur devrait être responsable de sa propre sécurité étant donné qu'il comprend les implications de choses comme des mots de passe faibles.

Certes, cette dernière partie est key, comme si l'utilisateur ne le savait pas mieux, vous devez le forcer à avoir un mot de passe plus sécurisé que celui qu'il souhaite utiliser. Mais une politique de mot de passe ne doit encourager que des mots de passe plus sécurisés et non limiter la force du mot de passe, comme l'illustre votre exemple.

J'ai rencontré cela personnellement avec le site Web de mon université. Mon mot de passe alphanumérique de longueur considérable ne répondait pas à la politique de mot de passe, ce qui décourageait certains (mais pas tous: /) les caractères spéciaux. Le résultat a été un mot de passe intentionnellement plus faible, car pour moi, il était plus difficile de se souvenir d'un mot de passe que je n'ai pas intentionnellement mis en mémoire.

Et surtout dans ce cas, je soupçonne que la "politique de mot de passe" était plus une excuse pour éviter une analyse / assainissement de chaînes sur le backend que c'était un moyen légitime d'encourager une meilleure sécurité. >

Enfin, les politiques de mot de passe, si elles sont mises en œuvre, devraient changer avec le temps. Autrement dit, ce qui aurait pu être considéré comme un mot de passe sécurisé dans les années 1990 ne l'est plus en 2016, lorsque le consommateur moyen peut tirer parti du cloud computing ou des grappes de GPU pour fournir une puissance informatique énorme et toujours croissante à vos mots de passe.



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