Dois-je imposer une longueur maximale aux mots de passe?

https://stackoverflow.com/questions/98768

01-07-2019
|

Question

Je peux comprendre qu'imposer une longueur minimale aux mots de passe a beaucoup de sens (pour sauver les utilisateurs d'eux-mêmes), mais ma banque exige que les mots de passe comportent entre 6 et 8 caractères, et J'ai commencé à me demander ...

Cela ne faciliterait-il pas les attaques par force brute? (Mauvais)
Cela implique-t-il que mon mot de passe est stocké non crypté? (Mauvais)

Si quelqu'un avec (avec un peu de chance) de bons professionnels de la sécurité informatique travaillant pour eux impose une longueur de mot de passe maximale, devrais-je envisager de faire la même chose? Quels sont les avantages / inconvénients de cela?

La solution

Les mots de passe sont hachés en 32, 40, 128, quelle que soit leur longueur. La seule raison d'une longueur minimale est d'éviter les mots de passe faciles à deviner. Il n'y a pas de but pour une longueur maximale.

Le XKCD obligatoire explique pourquoi vous ne rendez pas service à l'utilisateur si vous lui imposez une longueur maximale:

Autres conseils

Une longueur maximale spécifiée dans un champ de mot de passe doit être lue comme un AVERTISSEMENT DE SÉCURITÉ : Tout utilisateur sensible et soucieux de sa sécurité doit assumer le pire et s’attendre à ce que ce site stocke votre mot de passe littéralement (c’est-à-dire qu’il ne soit pas haché, comme l’explique epochwolf).

En cela, c'est le cas: (a) évitez si possible d'utiliser ce site comme un fléau [ils savent évidemment tout ce qu'il faut savoir sur la sécurité] (b) si vous devez utiliser le site, assurez-vous que votre mot de passe est unique - contrairement à tout autre mot de passe que vous utilisez ailleurs.

Si vous développez un site qui accepte les mots de passe, NE PAS mettre une limite de mot de passe ridicule, à moins que vous ne vouliez être taré avec le même pinceau.

[En interne, bien entendu, votre code peut traiter uniquement les premiers octets de 256/1028 / 2k / 4k (quels que soient) comme "significatifs". pour éviter de trouver des mots de passe gigantesques.]

Autoriser une longueur de mot de passe totalement illimitée présente un inconvénient majeur si vous acceptez le mot de passe de sources non fiables.

L'expéditeur peut essayer de vous donner un mot de passe si long qu'il en résulte un déni de service pour les autres personnes. Par exemple, si le mot de passe est 1 Go de données et que vous passez tout votre temps, acceptez-le jusqu'à épuisement de la mémoire. Supposons maintenant que cette personne vous envoie ce mot de passe autant de fois que vous êtes prêt à l'accepter. Si vous ne faites pas attention aux autres paramètres impliqués, cela pourrait conduire à une attaque par déni de service.

Définir la limite supérieure à quelque chose comme 256 caractères semble trop généreux par rapport aux normes actuelles.

Tout d’abord, ne supposez pas que les banques emploient de bons professionnels de la sécurité informatique. Ce n'est pas le cas .

Cela dit, la longueur maximale du mot de passe est sans valeur. Les utilisateurs doivent souvent créer un nouveau mot de passe (des arguments sur la valeur de l’utilisation de mots de passe différents sur chaque site, sauf pour le moment), ce qui augmente la probabilité qu’ils les écrivent simplement. Cela augmente également considérablement la susceptibilité aux attaques, quel que soit le vecteur, de la force brute à l’ingénierie sociale.

La limite de longueur maximale du mot de passe est maintenant découragée par le aide-mémoire d'authentification OWASP

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Citer tout le paragraphe:

Les mots de passe plus longs fournissent une plus grande combinaison de caractères et par conséquent rendent plus difficile la tâche de l'attaquant.

La longueur minimale des mots de passe doit être imposée par l'application.   Les mots de passe de moins de 10 caractères sont considérés comme faibles ([1]).   Bien que l'application de la longueur minimale puisse poser des problèmes de mémorisation des mots de passe chez certains utilisateurs, les applications doivent les encourager à définir des phrases secrètes (phrases ou combinaisons de mots) pouvant être beaucoup plus longues que les mots de passe habituels et beaucoup plus faciles à mémoriser.

La longueur maximale du mot de passe ne doit pas être trop basse, cela empêcherait les utilisateurs de créer des phrases secrètes. La longueur maximale typique est de 128 caractères.   Les phrases secrètes de moins de 20 caractères sont généralement considérées comme faibles si elles ne sont composées que de caractères latins minuscules. Chaque personnage compte !!

Assurez-vous que chaque caractère saisi par l'utilisateur est bien inclus dans le mot de passe. Nous avons vu des systèmes tronquer le mot de passe à une longueur inférieure à celle fournie par l'utilisateur (par exemple, tronqué à 15 caractères lorsqu'ils en ont entré 20).   Ceci est généralement géré en définissant la longueur de TOUS les champs de saisie du mot de passe afin qu'elle soit exactement identique à la longueur du mot de passe. Ceci est particulièrement important si la longueur maximale de votre mot de passe est courte, par exemple 20 à 30 caractères.

Une des raisons que je peux imaginer pour imposer une longueur de mot de passe maximale est si l'interface doit s'interfacer avec de nombreux systèmes back-end hérités, dont l'un impose lui-même une longueur de mot de passe maximale.

Un autre processus de réflexion pourrait consister à dire que si un utilisateur est obligé de choisir un mot de passe court, il est plus susceptible d’inventer du charabia au hasard qu’un pseudonyme ou un pseudo facile à deviner (par ses amis / sa famille). Cette approche n’est bien sûr efficace que si l’interface impose le mélange de chiffres et de lettres et rejette les mots de passe comportant des mots du dictionnaire, y compris des mots écrits en l33t-speak.

Une raison potentiellement valable d’imposer une longueur maximale de mot de passe est que le processus de hachage de celui-ci (en raison de l’utilisation d’une fonction de hachage lente telle que bcrypt) prend trop de temps; quelque chose qui pourrait être utilisé pour exécuter une attaque DOS contre le serveur.

Là encore, les serveurs doivent être configurés pour supprimer automatiquement les gestionnaires de demandes qui prennent trop de temps. Je doute donc que cela pose un gros problème.

Je pense que vous avez très raison sur les deux points. S'ils stockent les mots de passe hachés, comme ils le devraient, la longueur du mot de passe n'a aucune incidence sur leur schéma de base de données. Avoir une longueur de mot de passe ouverte ajoute une variable supplémentaire qu'un attaquant brutal-force doit prendre en compte.

Il est difficile de trouver une excuse pour limiter la longueur du mot de passe, en plus du mauvais design.

Le seul avantage que je peux constater avec une longueur de mot de passe maximale serait d'éliminer le risque d'attaque par débordement de mémoire tampon causée par un mot de passe excessivement long, mais il existe de bien meilleurs moyens de gérer cette situation.

Le stockage n’est pas cher, pourquoi limiter la longueur du mot de passe. Même si vous chiffrez le mot de passe plutôt que de le hacher, une chaîne de 64 caractères ne nécessitera pas beaucoup plus qu'une chaîne de 6 caractères à chiffrer.

Il est probable que le système de la banque superpose un système plus ancien, de sorte qu’ils n’ont pu laisser qu’un certain espace pour le mot de passe.

Ma banque le fait aussi. Il permettait n'importe quel mot de passe, et j'avais un 20 caractères. Un jour, je l'ai changée, et voilà qu'elle m'a donné un maximum de 8 et que j'avais coupé des caractères non alphanumériques qui étaient dans mon ancien mot de passe. Cela n'avait aucun sens pour moi.

Tous les systèmes back-end de la banque fonctionnaient auparavant lorsque j'utilisais mon mot de passe de 20 caractères avec des caractères non alphanumériques. Par conséquent, le support hérité ne pouvait pas en être la raison. Et même si c'était le cas, ils devraient toujours vous autoriser à utiliser des mots de passe arbitraires, puis créer un hachage qui correspond aux exigences des systèmes existants. Mieux encore, ils devraient réparer les systèmes existants.

Une solution de carte à puce ne me conviendrait pas. J'ai déjà trop de cartes telles qu'elles sont ... Je n'ai pas besoin d'un autre gadget.

Si vous acceptez un mot de passe de taille arbitraire, on suppose qu'il est tronqué pour une longueur de rideau pour des raisons de performances avant son hachage. Le problème avec la troncature est qu'au fur et à mesure que les performances de votre serveur augmentent, vous ne pouvez pas facilement augmenter la longueur avant la troncature car son hachage serait clairement différent. Bien sûr, vous pourriez avoir une période de transition où les deux longueurs sont hachées et vérifiées, mais cela utilise plus de ressources.

Ignorez les personnes qui disent de ne pas valider les mots de passe longs. Owasp dit littéralement que 128 caractères devraient suffire. Juste pour donner assez d’espace de respiration, vous pouvez en donner un peu plus, par exemple 300, 250, 500 si vous en avez envie.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Longueur du mot de passe Des mots de passe plus longs fournissent une plus grande combinaison de   caractères et par conséquent rendent plus difficile pour un attaquant de   devinez.

...

La longueur maximale du mot de passe ne doit pas être trop basse, cela empêcherait   les utilisateurs de créer des mots de passe. La longueur maximale typique est de 128   caractères . Les phrases secrètes de moins de 20 caractères sont généralement   considérés comme faibles s'ils ne sont constitués que de caractères latins minuscules.

Devrait-il y avoir une longueur maximale? C’est un sujet curieux en informatique car les mots de passe longs sont généralement plus difficiles à retenir, et donc plus susceptibles d’être écrits (un gros non-non pour des raisons évidentes). Les mots de passe plus longs tendent également à être davantage oubliés, ce qui, sans constituer nécessairement un risque pour la sécurité, peut entraîner des problèmes administratifs, une perte de productivité, etc. Les administrateurs qui estiment que ces problèmes sont pressants sont susceptibles d'imposer une longueur maximale aux mots de passe.

Personnellement, j’ai la conviction que chaque utilisateur a son propre problème. Si vous pensez pouvoir vous souvenir d'un mot de passe de 40 caractères, profitez-en d'autant plus!

Ceci étant dit, les mots de passe deviennent rapidement un mode de sécurité obsolète. L'authentification par carte à puce et par certificat s'avère très difficile, voire impossible, comme le dit le problème, et seule une clé publique doit être stockée sur le serveur. avec la clé privée de votre carte / ordinateur à tout moment.

Les mots de passe plus longs, ou phrases de passe, sont plus difficiles à déchiffrer en raison de leur longueur, et plus faciles à retenir que ceux nécessitant un mot de passe complexe.

Il vaut probablement mieux opter pour une longueur minimale assez longue (10 ans et plus), ce qui limiterait la longueur inutile.

Les systèmes hérités (déjà mentionnés) ou l’interface entre les systèmes des fournisseurs peuvent nécessiter une limite de 8 caractères. Il pourrait également s'agir d'une tentative malavisée de sauver les utilisateurs d'eux-mêmes. En le limitant de cette manière, vous obtiendrez trop de mots de passe pssw0rd1, pssw0rd2, etc. dans le système.

Une des raisons pour lesquelles les mots de passe ne peuvent pas être hachés est l'algorithme d'authentification utilisé. Par exemple, certains algorithmes de synthèse requièrent une version en texte brut du mot de passe sur le serveur car le mécanisme d'authentification implique le client et le serveur effectuent les mêmes calculs avec le mot de passe saisi (qui ne produit généralement pas la même sortie à chaque fois que le mot de passe est combiné à un 'nonce' généré de manière aléatoire, partagé entre les deux ordinateurs).

Cela peut souvent être renforcé car le résumé peut être en partie calculé, mais pas toujours. Un meilleur itinéraire consiste à stocker le mot de passe avec un cryptage réversible. Cela signifie donc que les sources de l’application doivent être protégées car elles contiennent la clé de cryptage.

L’autorisation Digst est là pour permettre l’authentification sur des canaux non cryptés. Si vous utilisez SSL ou un autre cryptage de canal complet, vous n'avez pas besoin d'utiliser les mécanismes d'authentification Digest, ce qui signifie que les mots de passe peuvent être stockés hachés (les mots de passe pouvant être envoyés en texte clair via le fil de manière sécurisée (pour une valeur donnée de safe).

Essayez de ne pas imposer de limitation sauf si cela est nécessaire. Soyez averti: cela pourrait et sera nécessaire dans beaucoup de cas différents. La gestion des systèmes existants est l’une de ces raisons. Assurez-vous de bien tester le cas des mots de passe très longs (votre système peut-il gérer des mots de passe longs de 10 Mo?). Vous pouvez rencontrer des problèmes de déni de service (DoS), car les fonctions de désactivation de clé (KDF) que vous utiliserez (généralement PBKDF2, bcrypt, scrypt) prendront beaucoup de temps et de ressources. Exemple concret: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

Seuls les mots de passe de 8 caractères sonnent faux. S'il doit y avoir une limite, alors au moins 20 caractères sont une meilleure idée.

Je pense que la seule limite qui devrait être appliquée ressemble à une limite de 2000 lettres ou à un niveau insignifiant, mais uniquement pour limiter la taille de la base de données si cela pose problème

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow