Question:
Quelle doit être la longueur maximale du mot de passe?
Mohamed
2010-11-12 10:22:36 UTC
view on stackexchange narkive permalink

La longueur minimale du mot de passe recommandée est d'environ 8 caractères, y a-t-il donc une longueur maximale standard / recommandée du mot de passe?

Cette question semble être devenue la question canonique sur ce site pour «combien de temps mon mot de passe utilisateur doit-il durer?», Mais la plupart des réponses semblent se concentrer sur les politiques de l'administrateur, et non sur la longueur recommandée pour un utilisateur.Quelqu'un avec suffisamment d'influence peut-il créer une nouvelle question adressée à la dernière et corriger les liens en double?Je poserais la question moi-même, mais elle serait probablement abattue comme un double.
La raison pour laquelle une telle question n'est pas nécessaire est dans [ce méta-post] (https://security.meta.stackexchange.com/a/2775/149193).
La longueur minimale du mot de passe n'est PAS un nombre défini.Quiconque vous fournit une valeur définie aujourd'hui est incorrecte demain, car la puissance de traitement augmente - 8 n'est plus un minimum valide depuis un certain temps.Max serait déterminé par la mise en œuvre de la plate-forme ou de l'application.
Douze réponses:
Rory McCune
2010-11-12 14:40:31 UTC
view on stackexchange narkive permalink

La réponse à celle-ci, comme à beaucoup de questions sur la sécurité, est "ça dépend".

Il y a plusieurs facteurs à prendre en compte lorsque l'on regarde la longueur du mot de passe. Tout d'abord, il y a certaines des choses contre lesquelles un mot de passe long est conçu pour protéger, ce qui est généralement une attaque par force brute de devinettes de mot de passe (en ligne ou hors ligne).

Pour deviner un mot de passe en ligne, si vous avez a une politique de verrouillage relativement agressive (par exemple, 3 tentatives incorrectes puis un verrouillage indéfini), les attaques contre un seul compte auront peu de chances de réussir à moins que l'attaquant n'ait une bonne idée de ce que sera le mot de passe.

Si vous recherchez des attaques contre une large population d'utilisateurs avec la même politique de verrouillage, où l'attaquant peut déterminer les noms d'utilisateur (par exemple, les forums Web), alors l'élément le plus important est probablement que les mots de passe utilisés ne sont pas

En passant, une chose à surveiller du côté du verrouillage de compte, c'est que les politiques agressives ici pour les applications en ligne peuvent rendre une attaque par déni de service assez facile, sans contre-mesures.

S'il y a un risque de force brute hors ligne, alors le mot de passe stren gth devient plus important. le problème ici est que l'amélioration de la puissance de traitement et des méthodes d'attaque en font une cible mobile en termes de force. En réalité, je dirais que vous envisagez plus de 10 caractères et une application forte du fait que les mots de passe ne figurent pas sur les listes de dictionnaires courantes (comme @andy dit que les phrases de passe sont une bonne option ici).

Un autre facteur à considérer ici est votre base d'utilisateurs et la manière dont l'application est utilisée. Dans certains cas, je dirais que des exigences de mot de passe très strictes peuvent en fait conduire à une application moins sécurisée. Si vous avez une application où les utilisateurs sont au même endroit (par exemple, beaucoup d'applications d'entreprise) et que vous rendez la politique de mot de passe très "forte" (à la fois en termes de longueur de mot de passe et d'exigences de rotation), il est probable que les utilisateurs commenceront écrire leurs mots de passe, ce qui va probablement à l'encontre de l'un des objectifs de sécurité de cette application en premier lieu.

Une bonne source de bien plus d'informations à ce sujet est un livre intitulé Authentication: From Passwords aux clés publiques

"De nombreux experts en sécurité tels que Bruce Schneier recommandent aux gens d'utiliser des mots de passe trop compliqués à mémoriser, de les noter sur papier et de les conserver dans un portefeuille." - http://en.wikipedia.org/wiki/Password#Write_down_passwords_on_paper
Andy
2010-11-12 11:24:58 UTC
view on stackexchange narkive permalink

Bonnes réponses jusqu'à présent, mais je voudrais suggérer une autre possibilité: les phrases de passe. Comme le suggère Jeff Atwood de StackOverflow, si vous n'êtes pas interdit par des limitations techniques, vous pouvez envisager d'autoriser et de suggérer des phrases de passe. Vous pourriez les appliquer, mais cela aliénerait probablement certains utilisateurs sur la plupart des sites. En raison de leur longueur, ils peuvent être beaucoup plus difficiles à déchiffrer, et ils peuvent également être plus faciles à retenir qu'un mot de passe comme "A1lUrB @ se!" ou des choses comme ça.

Ceci est un commentaire, pas une réponse.
Doug Kavendek
2010-11-19 23:13:51 UTC
view on stackexchange narkive permalink

Si vous allez hacher le mot de passe, pourquoi définir une limite supérieure?

Ce n'est pas comme si vous deviez vous soucier d'atteindre la limite maximale de caractères sur les champs de texte, basés sur le Web ou autre. Vous pouvez donc définir un maximum de quelques centaines de caractères juste pour limiter certaines conditions aux limites des champs de texte que vous utilisez.

Bien sûr, si vous parlez de générer un mot de passe que vous ' J'essaierai d'utiliser sur plusieurs sites, alors tant pis; personne ne semble être d'accord là-dessus. Pire encore, j'ai trouvé des sites qui ont des limites maximales de caractères différentes sur différents champs de saisie.Par conséquent, pour vous connecter, vous devez d'abord le saisir mal avant de recevoir un champ différent qui autorise plus de caractères. Bien sûr, si chaque site laissait simplement les capacités minimales attendues d'un champ de texte typique sans essayer de le limiter artificiellement, alors environ 2k caractères seraient autorisés, et vous n'auriez pas à vous en soucier du tout.

Modifié pour ajouter: quelque chose mentionné en passant ici m'a fait réfléchir:

vous devez adapter le travail de hachage à ce qui est disponible et raisonnable sur vos serveurs ou dispositifs. Par exemple, nous avons eu un bug mineur de déni de service dans Discourse où nous avons autorisé les gens à saisir jusqu'à 20 000 mots de passe de caractères dans le formulaire de connexion

Cela pourrait donc valoir la peine de mettre une limite raisonnable sur les deux définir et essayer des mots de passe si vous hachez des choses d'une manière censée être aussi coûteuse en calcul que possible. Quelques centaines de caractères peuvent encore empêcher les choses d'exploser trop, tout en étant bien plus qu'un utilisateur ne pourrait jamais essayer.

"_Si vous allez hacher le mot de passe, pourquoi fixer une limite supérieure? _" Peut-être parce que s'il est trop long, et s'il est généré aléatoirement, son entropie pourrait révéler la qualité de votre générateur de nombres aléatoires.
@Geremia Si quelques centaines d'octets de mot de passe exposent la qualité de votre RNG, vous rencontrez des problèmes plus importants que les limites de longueur de mot de passe.Définir une longueur maximale inférieure ne vous aide vraiment pas.
Alexandru Luchian
2010-11-12 10:39:47 UTC
view on stackexchange narkive permalink

Bruce Schneier a quelques articles intéressants sur les politiques de mot de passe.

Mots de passe du monde réel - couvrant la longueur des mots de passe, la complexité et les mots de passe courants.

Conseils sur les mots de passe - certaines choses à faire et à ne pas faire, notamment:

  • Utilisez un gestionnaire de mots de passe
  • Changez fréquemment les mots de passe. Je change le mien tous les six mois ...
  • Ne réutilisez pas d'anciens mots de passe.
  • N'utilisez PAS de mots de passe comprenant des mots du dictionnaire, des anniversaires, des noms de famille et d'animaux, des adresses ou toute autre information personnelle.
  • N'accédez PAS aux comptes protégés par mot de passe sur les réseaux Wi-Fi ouverts - ou sur tout autre réseau auquel vous ne faites pas confiance - à moins que le site ne soit sécurisé via https.

et bien d'autres

Modification des mots de passe - une discussion détaillée sur la fréquence à laquelle vous devez changer en fonction de l'utilisation et de l'environnement de menace .

Aussi http://www.wired.com/politics/security/commentary/securitymatters/2007/01/72458
-1 Est-ce juste moi ou est-ce que cela ne répond pas à la question?
https://security.stackexchange.com/a/536/2572 répond en fait à la question, et bien.
Thomas Pornin
2013-02-02 21:01:47 UTC
view on stackexchange narkive permalink

Il ne devrait pas y avoir de longueur maximale de mot de passe - si l’utilisateur accepte d’utiliser un mot de passe très long, il devrait être félicité et non bloqué .

Le logiciel étant ce qu'il est, plusieurs systèmes imposeront une limite sur la taille du mot de passe, principalement en raison d'un problème d'interface graphique, d'une mauvaise programmation ou d'une rétrocompatibilité avec des systèmes beaucoup plus anciens. Par exemple, les anciens systèmes Unix utilisaient un processus de hachage de mot de passe qui n'utilisait que les huit premiers caractères et ignorait totalement tous les autres. De même, les anciens systèmes Windows avaient une limite interne à 14 caractères. Par conséquent, il est préférable que le mot de passe, lorsqu'il est tronqué à ses 14 premiers caractères, soit toujours "fort".

Cependant, la seule limite sur la taille maximale du mot de passe doit être la patience de l'utilisateur. Il est inutile d'appliquer quoi que ce soit ici.

_ Sauf_ il y a une bonne raison technique.Un exemple étant l'utilisation de BCRYPT par PHP signifie que les mots de passe sont tronqués au-delà de 72 caractères.
tylerl
2013-02-02 22:14:21 UTC
view on stackexchange narkive permalink

Un minimum courant aujourd'hui est de 12 caractères, ce qui est à peine assez grand pour empêcher le craquage par force brute par une organisation raisonnablement bien financée dans un délai raisonnable.

Jusqu'à la longueur maximale; voici quelques réflexions: un mot de passe de plus de quelques centaines d'octets est presque certainement malveillant (par exemple, tentative d'injection SQL). Notez également que si vous hachez votre mot de passe (et si vous ne l'êtes pas, vous devez recommencer), les mots de passe plus longs que votre sortie de hachage n'ajoutent plus d'entropie. Notez que par «plus long», je veux dire le même nombre de bits dans votre espace de clé, pas la même longueur de caractère. Ainsi, si autoriser des mots de passe plus longs que la longueur de hachage devrait être autorisé pour des raisons de commodité, cela n'aurait pas de sens d'un point de vue mathématique qu'une telle chose soit obligatoire .

Le fait d'exiger une casse mixte double la taille de votre alphabet, ce qui produit d'énormes retours de complexité et devrait probablement être requis. Exiger des caractères numériques ajoute peut-être 20% de plus à votre alphabet, ce qui n'est pas aussi important, et exiger des symboles ajoute peut-être 16% à 40% de plus en plus (selon les symboles que vous comptez), et encore une fois, non un retour tout aussi important, mais ne devrait certainement pas être interdit.

Je n'aurais pas besoin de casse mixte ou de toute autre classe de caractères. Je préfère utiliser une sorte d'estimateur d'entropie sur le mot de passe, puis exiger une valeur minimale pour sa sortie. Les utilisateurs qui utilisent moins de classes de caractères ont donc besoin d'un mot de passe plus long pour compenser.
Que diriez-vous si nous abandonnons la ponctuation parce que certaines personnes écrivent des mots de passe et que les points-virgules écrits ressemblent à des deux-points, les points ressemblent à des virgules, etc. S'ils utilisent un gestionnaire de mots de passe logiciel, certaines polices peuvent ne pas être adaptées aux personnes malvoyantes qui lire la ponctuation. Bien sûr, les attaquants devraient aller de l'avant et supposer qu'il y a de la ponctuation.
Sairam
2010-11-12 10:56:07 UTC
view on stackexchange narkive permalink

Personnellement, j'utiliserais un générateur de mots de passe (comme lastpass.com ou 1password) pour générer et utiliser des mots de passe de 8 caractères minimum et 32 ​​caractères maximum (car tous les sites ne prennent pas en charge une longueur de mot de passe supérieure à 10 ou 15) et utilisent un mot de passe principal pour l'authentification (cela dépend encore une fois de votre confiance sur des sites comme lastpass.com) ou un utilitaire 1password chiffré côté client pour Mac et Windows).

Il n'est pas conseillé d'utiliser un ensemble de mots de passe pour tous les sites. Les forums en particulier m'envoient des mots de passe en texte brut. Certains sites ont la fonction d'envoyer un mot de passe simple au cas où vous utiliseriez la fonction "Mot de passe oublié".

Habituellement, les restrictions sont définies sur le serveur (pour les sites Web). Nous devons blâmer les serveurs que nous utilisons pour ne pas imposer de restrictions sur les mots de passe des utilisateurs.

En bref, utilisez des mots de passe différents à chaque fois. Si vous avez plus de 10 à 15 mots de passe à retenir, il est temps de commencer à utiliser un gestionnaire de mots de passe «sécurisé». (Pour mémoire, le gestionnaire de mots de passe Firefox n'est pas du tout sécurisé)

Btw, si un serveur a une restriction sur la longueur du mot de passe, c'est généralement à cause d'autres vulnérabilités: par exemple le mot de passe est stocké en clair, et donc le champ de base de données attribué est ce qui limite la longueur.
Pouvez-vous nous expliquer que le gestionnaire de mots de passe de Firefox n'est pas sécurisé?
Firefox et d'autres navigateurs comme Chrome et IE ont un gestionnaire de mots de passe, mais les mots de passe peuvent facilement être récupérés et lus par des addons, des plugins et d'autres logiciels sur votre système. Firefox a une fonctionnalité pour sécuriser le gestionnaire de mots de passe avec un mot de passe principal. Je me demande si AviD ou quelqu'un d'autre voudrait commenter la sécurité de FF avec la fonction de mot de passe principal activée.
Roger C S Wernersson
2010-11-17 13:45:28 UTC
view on stackexchange narkive permalink

16 caractères.

Cela vous donne 96 bits selon Wikipédia, ce qui est bien au-delà de tout ce qui est crackable selon cet article.

Personnellement, j'utilise un programme de mot de passe pour mon téléphone mobile, combiné avec la fonction de mot de passe principal de Firefox. Mon mot de passe principal comporte plus de 25 caractères et est basé sur Dice Ware, ce qui le rend assez facile à retenir. Presque tous mes mots de passe sont régénérés aléatoirement, puisque Firefox m'en souvient de toute façon.

Terrible conseil, 16 caractères sont trop peu si vous souhaitez utiliser une combinaison de mots séparés par des espaces, qui sont de loin plus sûrs. Je ne veux pas être obligé d'utiliser une fonction de mot de passe principal pour mon e-mail, et il comporte 35 caractères.
Accordé. J'allais chercher une réponse courte et utile. 16 caractères aléatoires, majuscules et minuscules, chiffres et caractères spéciaux est un bon minimum. Cinq mots de dés est supérieur à cela.
Mais * pourquoi * est-ce suffisant?J'aime le fait que ce soit une réponse pratique, mais elle devrait être accompagnée d'une explication, je pense.
Ce serait une question différente.La réponse devrait être dans l'article de Wikipédia auquel je renvoie.
geoffc
2010-11-19 23:43:26 UTC
view on stackexchange narkive permalink

J'étais chez un client où l'agent de sécurité était fou. Il voulait utiliser toutes les politiques de complexité des mots de passe possibles. (Novell eDirectory a BEAUCOUP de problèmes de complexité de mot de passe, et il voulait utiliser un plugin supplémentaire pour en ajouter plus!)

Au point qu'il serait impossible de générer un mot de passe dont on puisse se souvenir. Je m'attendais à ce que les masses non lavées le trouvent, et le goudronnent et le plumes après sa mise en œuvre.

En d'autres termes, vous pouvez aller trop loin.

Désolé, tu m'as perdu quelque part.Vous avez dit "il était impossible de générer un mot de passe dont on puisse se souvenir".Ça a du sens.Mais alors vous dites: "En d'autres termes, vous pouvez aller trop loin."Je comprends que vous l'avez trouvé ennuyeux, mais la question est de savoir dans quelle mesure un mot de passe devrait être fort.Avez-vous constaté que cette politique entraînait des mots de passe plus faibles et donc une sécurité réduite?Ou cela a-t-il considérablement nui à la productivité de l'entreprise?Ou n'était-ce pas le cas et s'agissait-il d'une très bonne politique qui, en 2010 ou avant, était nouvelle pour les gens?
Luc
2019-01-10 06:02:37 UTC
view on stackexchange narkive permalink

Conseil

En 2019, le caractère aléatoire requis pour un mot de passe / phrase de passe sécurisé est:

  • 12 caractères générés aléatoirement avec des minuscules, des majuscules et des chiffres; ou
  • 6 mots générés aléatoirement. (Ne choisissez pas les mots vous-même! Cela crée des modèles.)

Il est impossible de se souvenir de vingt d'entre eux, alors ne mémorisez que quelques mots importants que vous utilisez régulièrement . Par exemple, vous pouvez mémoriser celui de votre compte de messagerie et celui de votre gestionnaire de mots de passe. Pour tout le reste, stockez les mots de passe dans un gestionnaire de mots de passe.

Pertinent: L'utilisateur moyen a-t-il vraiment besoin d'un gestionnaire de mots de passe?
La réponse la plus votée est clairement «oui ".

Pertinent: Dans quelle mesure les gestionnaires de mots de passe sont-ils sûrs?
De la première réponse, par paj28 (c'est moi qui souligne):

pour la plupart des gens, ces risques sont acceptables, et je dirais que l’approche d ' utiliser un gestionnaire de mots de passe [pour] la plupart de vos mots de passe est meilleure que d'utiliser le même mot de passe partout - ce qui semble être la principale alternative. Mais je ne stockerais pas tous les mots de passe là-dedans; faites un effort pour mémoriser vos plus importants, comme les services bancaires en ligne.

Les gestionnaires de mots de passe couramment mentionnés sont KeePass (X), 1Password et LastPass. Celui de votre navigateur dépend: lorsque vous utilisez Firefox avec un mot de passe principal, c'est presque aussi bon que d'utiliser un mot de passe dédié. Si votre navigateur ne nécessite pas de mot de passe avant de pouvoir accéder aux mots de passe, il n'est pas très sécurisé (mais les détails dépendent de l'implémentation exacte, qui est tout un sujet en soi).

Développeurs

Lorsque vous créez une application, voici quelques considérations utiles:

Comment hacher les mots de passe en toute sécurité?
Résumé: utilisez Scrypt ou Argon2, aussi lentement que vous peut aller. Si ceux-ci ne sont pas disponibles, Bcrypt ou PBKDF2 sont des alternatives acceptables. Ajoutez à la fois sel et poivre.

Dois-je avoir une longueur maximale de mot de passe?
Résumé: uniquement contre les attaques DoS, donc quelques kilo-octets environ.

Implémenter le hachage de mot de passe côté client
Divulgation complète: je crée un lien vers ma propre réponse car je pense que c'est le plus complet. Assurez-vous également de lire les opinions des autres.

Détails

Vous vous demandez peut-être "pourquoi mon code PIN est-il à seulement 4 chiffres? C'est suffisant pour sécuriser mon compte bancaire!" Il y a une question dédiée à cela, mais le résumé est deux choses: vous avez besoin de votre carte bancaire pour l'accès (un deuxième facteur d'authentification), et la puce vous verrouille après 3 tentatives.

Les sites Web sont beaucoup plus indulgents, donc un attaquant peut faire plus de tentatives. De plus, les sites Web devraient être piratés tôt ou tard, après quoi l'attaquant peut déchiffrer efficacement votre mot de passe haché.

La plupart des sites Web stockent votre mot de passe avec une sorte de cryptage unidirectionnel, appelé hachage. Il n'y a pas de clé de déchiffrement. En appliquant à nouveau le même algorithme de hachage, le système peut comparer le mot de passe (que vous venez de saisir) à celui stocké (à partir de la base de données) et savoir s'ils sont égaux. Mais avec uniquement la base de données, vous ne pouvez pas connaître le mot de passe d'origine.

Dans le passé, les méthodes de hachage rapide étaient courantes. Cela signifie également qu'un attaquant, qui a obtenu le hachage, peut demander à son ordinateur de faire des milliards de tentatives par seconde sur un ordinateur de jeu moyen. En supposant dix milliards de tentatives par seconde, un mot de passe aléatoire de 11 caractères tient pendant environ 165 ans. Et ce n'est qu'un joueur, imaginez que vous avez accès aux données de l'entreprise qui intéressent certains concurrents étrangers: avec une puissance de calcul supplémentaire, ces 165 années se transforment soudainement en quelques mois de craquage. Et l'année prochaine, il y aura de nouveaux processeurs plus rapides pour le même prix, réduisant à nouveau la force. C'est pourquoi douze caractères est le minimum pour un mot de passe fort: ce caractère supplémentaire ajoute littéralement dix mille ans au temps de craquage (165 ans contre 10230 ans), et est sécurisé dans un avenir prévisible.

Soit dit en passant, il est facile de calculer la force du mot de passe: variations ^ length / guesses_per_time . Les variations correspondent au nombre d'éléments uniques et la longueur correspond au nombre d'éléments que vous utilisez. Donc, si vous utilisez uniquement des chiffres, il existe dix variantes (de 0 à 9). Si vous utilisez des mots d'un dictionnaire, c'est cependant le nombre de mots dans le dictionnaire. Ensuite, guesses_per_time correspond à la vitesse à laquelle vous supposez que l'attaquant peut craquer. Une valeur raisonnable est de dizaines de milliards par seconde.
Exemple: 10 ^ 14 / 10e9 / 3600 vous montre combien d'heures il faudrait pour déchiffrer un code de 14 chiffres, lorsque vous supposez 10e9 tentatives par seconde (il y a 3600 secondes dans une heure, 60 * 60).

Certains sites Web sont intelligents et utilisent un algorithme de hachage lent. Nous ne pouvons pas dire lesquels il s'agit, car le serveur effectue le hachage, vous ne pouvez donc pas le voir de l'extérieur. Si tel est le cas, alors une seule estimation prendra beaucoup plus de temps à calculer (pour le serveur, mais aussi pour un attaquant). Dans un cas raisonnable, un attaquant bien financé ne peut faire que cinquante mille suppositions par seconde, auquel cas un mot de passe à 9 caractères suffirait. Mais 9 caractères aléatoires sont déjà très difficiles à mémoriser pour de nombreux comptes différents, surtout si vous ne les utilisez pas tous régulièrement. Par conséquent, un gestionnaire de mots de passe est nécessaire pour vraiment avoir une sécurité dans les mots de passe.

Mais est-il vraiment nécessaire d'avoir des mots de passe uniques? Pourquoi ne pas réutiliser des mots de passe forts sur quelques sites différents? Parce que les sites Web sont fréquemment compromis. Ce n'est pas un événement quotidien, mais essayez d'entrer votre (vos) adresse (s) e-mail sur haveibeenpwned.com: cela arrive certainement beaucoup. C'est ainsi que les comptes sont le plus fréquemment piratés: la réutilisation du mot de passe. Les compromis des gestionnaires de mots de passe sont beaucoup moins courants.

Coach David
2019-01-09 23:36:01 UTC
view on stackexchange narkive permalink

Il me semble que la longueur et la complexité du mot de passe sont allées trop loin. Lorsqu'il est associé à de bonnes politiques de verrouillage, 10 devrait être plus que suffisant. Actuellement, 4 numéros suffisent pour sécuriser les transactions au guichet automatique. Les verrous de téléphone vont aussi bas que 4 mais nécessitent souvent 6. La politique de verrouillage est la partie la plus importante de la formule. Si vous demandez à un utilisateur de contacter quelqu'un pour déverrouiller un compte, la taille peut être plus petite. Si le verrouillage est effectué pendant un certain temps, le mot de passe doit refléter.

La différence est que vous devez être physiquement en possession de votre téléphone pour essayer de le déverrouiller.Si 10000 personnes ont un mot de passe à 4 chiffres, vous aurez de bonnes chances d'accéder à l'un des comptes simplement en essayant 1 mot de passe sur chacun.
@AndrolGenhald Je dirais que la différence est que vous avez un nombre limité de tentatives sur un téléphone ou une carte à puce (comme une carte bancaire ou une carte SIM): après trois à cinq tentatives, vous êtes bloqué ou limité par le taux.Les recommandations de mot de passe gardent à l'esprit que quelqu'un peut lui appliquer un craquage en ligne ou hors ligne, où vous pouvez faire entre 100 et quelques milliards de tentatives par seconde.Il n'y a pas beaucoup de sites Web qui appliquent une limitation de taux, et il est préférable de supposer que la base de données est volée à un moment donné.
@CoachDavid Voir cette question pourquoi ce n'est pas si simple que "4 chiffres devraient suffire pour tout": [Force du mot de passe et code PIN à 4 banques?] (Https://security.stackexchange.com/q/61814/10863)
@Coach David - vous feriez mieux de poser une question ici si vous cherchez des informations
Alberto Salvia Novella
2020-02-04 01:21:57 UTC
view on stackexchange narkive permalink

Le critère que j'utilise pour les mots de passe est le suivant:

  • Être généré par le site Web lui-même, de sorte que les utilisateurs ne peuvent pas utiliser de mots de passe non sécurisés de par leur conception.
  • Être généré par ordinateur , donc son schéma est vraiment chaotique. Les mots de passe générés par l'homme ont des modèles prévisibles.
  • Être uniquement composé de lettres minuscules , il est donc mémorable et suffisamment rapide pour être saisi sur tout type d'appareil et de clavier.
  • Faites 20 caractères . Il contient donc suffisamment d ' entropie pour être incassable par un botnet lorsque les tentatives ne sont pas artificiellement étirées, comme lorsque la police essaie de déchiffrer votre stockage en utilisant Echelon.

Lorsque je rédige le mot de passe, je le divise en groupes de quatre, il est donc plus facile à retenir. Par exemple:

  bxkx osnt spmf jmwz ivyj  


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