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?
Récemment, j'ai vu la capture d'écran suivante sur Twitter , décrivant une politique de mot de passe évidemment terrible:
Je me demande ce qui est pire pour la force du mot de passe. N'ayant aucune politique de mot de passe ou mauvaise politique de mot de passe (comme décrit dans la capture d'écran)?
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, beaucoup de mots de passe seront probablement [a-z] * 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 ne sont que 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é à déchiffrer un mot de passe. Si vous me donnez une base de données de hachage de mot 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 de hachage de mot de passe, sans politique de mot de passe, il est très facile de casser n'importe quel mot de passe mais plus difficile de casser la plupart des mots de passe. Avec une mauvaise politique comme celle donnée, il est plus facile de casser tous les mots de passe mais légèrement plus difficile de casser le premier, très probablement.
Si votre souci est de savoir à quel point il est difficile de casser votre propre mot de passe, sans aucune politique, vous pouvez utiliser un mot de passe aléatoire sécurisé de 20 caractères si vous le souhaitez. Avec la stratégie 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, etc., mais cela est hors de portée ici). Ainsi, en tant qu'utilisateur du site Web/service, une mauvaise politique de mot de passe est bien pire.
Si vous le regardez du point de vue organisationnel, une mauvaise politique de mot de passe est bien pire qu’aucune.
Aucune politique de mot de passe ne signifie, probablement 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 est venu avec cette merde. Cela signifie qu'ils n'ont probablement aucune idée de la sécurité.
En fin de compte, si vous pouvez mettre en œuvre une mauvaise politique de mot de passe, vous pouvez également en mettre une bonne afin qu'il n'y ait jamais d'excuse pour une mauvaise politique de mot de passe. Changer simplement la politique en "Un mot de passe doit être composé d'au moins 8 caractères" augmenterait beaucoup la sécurité et n'est pas difficile à faire.
Maintenant, je me demande ce qui est pire pour la force des mots de passe. Vous n'avez aucune politique de mot de passe ou une mauvaise politique de mot de passe comme sur la photo?
Les exigences de force du mot de passe que vous avez mentionnées font plus de mal que de bien, en particulier la longueur maximale.
- Ils utilisent peut-être une très ancienne routine de hachage non sécurisée. (donc une longueur max)
- Dans certains domaines, cela favorise la commodité plutôt que la sécurité.
(aucun espace n'est utile pour représenter un mot de passe en texte brut,
insensible à la casse, il n'y a donc pas d'appels de prise en charge du verrouillage des majuscules) - D'autres articles sont tout simplement stupides.
Ventilation détaillée
Votre mot de passe doit:
- Faites 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 schéma de hachage hérité qui tronque tous les caractères, sauf les 8 premiers.
Par exemple, les mots de passe des comptes d'utilisateurs Solaris 10 utilisaient un tel schéma par défaut, donc les mots de passe comme passwordSup@rsecur☺ ont été tronqués à password !!! La valeur par défaut de Solaris 11 ne présente pas cette lacune.
Dans ce cas
Les développeurs devraient travailler sur la migration vers une meilleure routine de hachage qui prend en charge les longueurs de mot de passe au-delà de 8.
Jusqu'à ce qu'un tel correctif soit déployé, la longueur maximale est saine.
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: ...
Ce sont un must é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), il 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 pour laquelle je vois cela est qu'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 du logiciel est médiocre (non sécurisée).
Une meilleure stratégie consiste à interdire les recherches et à autoriser uniquement 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 de base.
- Ne commence pas par
?ou!
Très étrange, mais pas un tueur significatif d'entropie de mot de passe.
- Ne commencez pas avec trois personnages 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. Il s'agit d'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 planifié obligatoire. Les résultats probables sont:
- Les utilisateurs noteront leur mot de passe au lieu d'utiliser leur mémoire,
- Ou, 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.
Une mauvaise politique comme celle-ci est pire qu’aucune.
Cette politique signifie que les personnes qui utilisent normalement "123" auront désormais un mot de passe un peu plus sécurisé, mais il reste faible. Cela signifie également que les personnes utilisant quelque chose comme `` fzFEZ # 5 $ 3rt4564ezezRTyht '' (généré de manière aléatoire), ou simplement: `` chat saute par-dessus le mur peint en marron412 '' (entropie forte), auront désormais un mot de passe beaucoup plus faible.
Les personnes utilisant des mots de passe faibles seront de toute façon piratées dans ce cas (car cette politique restrictive et faible, et l'attaquant étant en mesure de définir des règles d'attaque spécifiques). Mais les gens qui utilisent normalement des mots de passe forts le feront également.
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.
à mon avis, n'en avoir aucun serait mieux. Voici une liste de raisons:
- Ces politiques font que les gens ont tendance à y écrire des mots de passe et à les coller sur les moniteurs ou similaires. (quelle sécurité un mot de passe fournit-il?)
- Ces règles sont facilement déduites et (en utilisant ce type de boîtes) même annoncées à tout intrus potentiel. (Par exemple, donnons à la personne que nous voulons garder les `` règles '' de la façon dont nos mots de passe sont ainsi, ils n'ont qu'à faire un ensemble limité ...)
- L'entropie d'un mot de passe s'améliore considérablement en les allongeant. 8 est de nos jours suffisamment banal pour qu'une attaque puisse utiliser un appareil mobile pour forcer un mot de passe par la force brute.
- la règle de mélanger les cas et de 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 nécessiter de mot de passe, comme:
- 2 Authentification par facteur.
- Authentification du périphérique secondaire.
- Authentification par carte à puce.
Ces politiques semblent être conçues par une personne qui ne comprend pas bien comment les menaces à un mot de passe affectent 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 nécessitent la mise en œuvre de certaines d'entre elles (pensez au secteur de la santé ou à certaines utilisations gouvernementales).
Aucun n'est meilleur que celui illustré, en particulier en raison de la limite de 8 caractères.
Les 8 combos de caractères peuvent être testés 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 grand, pas de mots de dictionnaire, etc.), celui montré est une blague qui n'est pas très drôle. En somme, 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 des mots terribles.
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?
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, car elle empêche quiconque d'avoir un bon mot de passe.
"Votre mot de passe doit contenir au moins deux caractères" est une mauvaise politique de mot de passe qui est certainement meilleure que de n'avoir aucune politique, car elle permet à quiconque d'utiliser un bon mot de passe et empêche certains mauvais mots de passe.
Il existe déjà un certain nombre de bonnes réponses, mais j'aime toujours regarder cela sous un angle légèrement différent. Lorsque vous envisagez la façon dont quelque chose affectera les tentatives de piratage d'un mot de passe, vous devez voir comment ils tenteront de le faire. Fondamentalement, cela se résume à deux méthodes. Force brute et devinettes "intelligentes" permettent donc de regarder ces deux-là.
1) Force brute.
C'est exactement ce que ça ressemble. Ils essaient tous les mots de passe possibles. C'est le classique qui essaie toutes les broches 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 supposition. Ici, la règle de mot de passe peut être excellente et éliminer complètement la force brute comme option viable en raison de l'exigence à 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 pour un attaquant disposant de suffisamment de ressources.
Étant donné que les règles dans ce cas semblent suggérer fortement quelque chose d'assez ancien sur le back-end, il est tout à fait possible, sinon peu 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 ne respectant pas la casse, ce qui réduit les caractères possibles de ~ 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 faibles hachages, il semble très probable que les règles sont effectivement catastrophiques et si elles ne le sont pas maintenant, elles sont certainement danger de devenir catastrophique dans un avenir proche car la puissance de calcul augmente le taux de craquage. Un mot de passe de plus de 8 caractères peut être nécessaire pour être sécurisé, mais il ne le permet pas réellement.
Est-il possible de forcer brutalement les 8 mots de passe de caractères dans une attaque hors ligne?
2) Deviner "intelligent"
À un moment donné, la méthode de la force brute devient impraticable, il faudrait des mois pour tester tous les mots de passe, voire impossible, il faudrait des millénaires pour les tester tous, et la devinette "intelligente" prend le dessus. C'est là que vous voyez les attaques de dictionnaire, soit des mots littéraux du dictionnaire ou 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 à changer des choses pour faire différentes variantes de ces mots de passe. Ajouter un chiffre et 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 du mot de passe. Faire 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 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 la fissuration ait atteint ce point, les règles de mot de passe qu'ils ont données finiraient par être incorporées dans les règles que l'attaquant a utilisées pour générer son mot de passe possible. Ici, leurs règles ne sont pas aussi catastrophiques, mais conduiraient à des mots de passe possibles beaucoup moins valides, ce qui accélérerait le craquage. Cela conduirait également à des mots de passe très prévisibles avec des symboles/chiffres ajoutés au début/à la fin du mot de passe ou dans le cadre d'une substitution très prévisible.
Si les utilisateurs choisissaient des mots de passe au hasard, les politiques de mots 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 de choisir un mot de passe plus fort sans limiter indûment l'espace du mot de passe.
Cette politique comporte de bons et de mauvais aspects.
avoir 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 composant basé sur un nombre.
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.
Inclure au moins un caractère spécial
Encore une fois, 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 beaucoup de différence.
caractères répétés interdits au début
Probablement une bonne chose, signifie que 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 une idée des mots de passe décents, cela fera probablement plus de mal que de bien.
Je vais emprunter 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, améliorez un peu l'utilisation du MD5.
Ou, mieux encore, SHA-1.
Peut-être qu'ils ajoutent du sel.
Peut-être utiliser crypt ().
Peut-être alors ajouter du poivre.
Pourtant, un GPGUP peut graver des milliards de hachages de mot de passe en une seconde. Alors quoi d'autre?
SHA-2-512 avec 128 bits de sel. Bien mieux, le GPGPU peut faire beaucoup de ces choses.
Passez à bcrypt. Bien mieux. Maintenant, nous dépassons le point où un seul GPGPU peut tout simplement les graver rapidement.
Changer pour PBKDF2, avec du sel et du poivre et 10 000 tours.
Jusqu'à cela pour crypter, et maintenant un mot de passe très court est "non craquable" car l'algorithme est si lent.
Voici un tablea qui pourrait aider à l'expliquer:
Tries/sec
NTLM 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 est meilleur qu'un grand haché avec MD5.
Cela revient vraiment à l'utilisateur final. À mon avis, 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 les mots de passe faibles.
Certes, cette dernière partie est essentielle, comme si l'utilisateur ne savait pas mieux, vous devriez le forcer à avoir un mot de passe plus sécurisé que ce qu'il veut utiliser. Mais une politique de mot de passe ne devrait qu'encourager des mots de passe plus sécurisés et ne pas limiter la force des mots de passe, comme l'illustre votre exemple.
Je l'ai rencontré personnellement avec le site Web de mon université. Mon mot de passe alphanumérique d'une longueur considérable ne satisfaisait pas à cette 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 me souvenir d'un mot de passe que je n'ai pas intentionnellement mémorisé.
Et surtout dans ce cas, je soupçonne que la "politique de mot de passe" était plus une excuse pour éviter une analyse/désinfection des 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. C'est-à-dire que 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 injecter une quantité énorme et toujours croissante de puissance informatique sur vos mots de passe.