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

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 a une exigence que les mots de passe comportent entre 6 et 8 caractères, et j'ai commencé à me demander ...

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

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

Les mots de passe sont hachés à 32, 40, 128, quelle que soit la longueur. La seule raison pour 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 expliquant pourquoi vous ne rendez pas service à votre utilisateur si vous imposez une longueur maximale:

Une longueur maximale spécifiée dans un champ de mot de passe doit être lue comme un AVERTISSEMENT DE SÉCURITÉ . Tout utilisateur sensé et soucieux de la sécurité doit supposer le pire et s'attendre à ce que ce site stocke votre mot de passe littéralement (c'est-à-dire non haché, comme expliqué par epochwolf).

Dans ce cas, c'est le cas:

1. Évitez d'utiliser ce site comme la peste si possible. Ils ne savent évidemment rien de la sécurité.
2. Si vous devez vraiment utiliser le site, assurez-vous que votre mot de passe est unique - contrairement à tout mot de passe que vous utilisez ailleurs.

Si vous développez un site qui accepte les mots de passe, ne mettez pas une limite de mot de passe idiote, à moins que vous ne vouliez être goudronné avec le même pinceau.

[En interne, bien sûr, votre code peut ne traiter que les premiers 256/1024 / 2k / 4k / (peu importe) comme "significatifs", afin d'éviter de croquer des mots de passe gigantesques.]

Permettre une longueur de mot de passe complètement illimitée présente un inconvénient majeur si vous acceptez le mot de passe provenant de sources non fiables.

L'expéditeur pourrait essayer de vous donner un mot de passe si long qu'il en résulterait un déni de service pour d'autres personnes. Par exemple, si le mot de passe est de 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 le souhaitez. Si vous ne faites pas attention aux autres paramètres impliqués, cela pourrait conduire à une attaque DoS.

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

Premièrement, ne supposez pas que les banques ont de bons professionnels de la sécurité informatique qui travaillent pour elles. Pas beaucoup .

Cela dit, la longueur maximale du mot de passe est sans valeur. Il oblige souvent les utilisateurs à créer un nouveau mot de passe (arguments sur la valeur de l'utilisation de mots de passe différents sur chaque site mis à part pour le moment), ce qui augmente la probabilité qu'ils les écrivent simplement. Cela augmente également considérablement la vulnérabilité aux attaques, par n'importe quel vecteur, de la force brute à l'ingénierie sociale.

La définition d'une longueur maximale de mot de passe inférieure à 128 caractères est désormais déconseillée par la feuille de triche d'authentification OWASP

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

Citant l'ensemble du paragraphe:

Les mots de passe plus longs fournissent une plus grande combinaison de caractères et, par conséquent, rendent la tâche plus difficile à deviner pour un attaquant.

La longueur minimale des mots de passe doit être appliqué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 causer des problèmes de mémorisation des mots de passe chez certains utilisateurs, les applications devraient les encourager à définir des phrases de passe (phrases ou combinaison de mots) qui peuvent être beaucoup plus longues que les mots de passe classiques et pourtant beaucoup plus faciles à retenir.

La longueur maximale du mot de passe ne doit pas être définie trop bas, car cela empêchera les utilisateurs de créer des phrases 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ées comme faibles si elles ne contiennent que des caractères latins minuscules. Chaque personnage compte !!

Assurez-vous que chaque caractère saisi par l'utilisateur est effectivement inclus dans le mot de passe. Nous avons vu des systèmes qui tronquent le mot de passe à une longueur plus courte que ce que l'utilisateur a fourni (par exemple, tronqué à 15 caractères quand ils ont entré 20). Ceci est généralement géré en définissant la longueur de TOUS les champs de saisie de mot de passe exactement la même longueur que la longueur maximale du mot de passe. Ceci est particulièrement important si la longueur maximale de votre mot de passe est courte, comme 20 à 30 caractères.

Une des raisons que je peux imaginer pour appliquer une longueur de mot de passe maximale est si le frontend doit s'interfacer avec de nombreux backends système hérités, dont l'un applique lui-même une longueur de mot de passe maximale.

Un autre processus de réflexion pourrait être que si un utilisateur est obligé d'utiliser un mot de passe court, il est plus susceptible d'inventer du charabia aléatoire qu'un slogan ou un surnom facilement deviné (par ses amis / sa famille). Cette approche n'est bien sûr efficace que si l'interface impose le mélange de chiffres / lettres et rejette les mots de passe qui ont des mots du dictionnaire, y compris les mots écrits en l33t-speak.

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

Là encore, les serveurs doivent être configurés pour supprimer automatiquement les gestionnaires de requêtes qui prennent trop de temps. Je doute donc que ce soit vraiment un problème.

Je pense que vous avez parfaitement 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'affecte en rien leur schéma de base de données. Avoir une longueur de mot de passe ouverte jette une autre variable qu'un attaquant par force brute doit prendre en compte.

Il est difficile de voir une excuse pour limiter la longueur du mot de passe, en plus d'une mauvaise conception.

Le seul avantage que je peux voir à une longueur de mot de passe maximale serait d'éliminer le risque d'attaque par débordement de tampon causé par un mot de passe trop long, mais il existe de bien meilleures façons de gérer cette situation.

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 suffisamment d'espace pour respirer, vous pouvez donner un peu plus, disons 300, 250, 500 si vous en avez envie.

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

Longueur du mot de passe Les mots de passe plus longs fournissent une plus grande combinaison de caractères et, par conséquent, rendent la tâche plus difficile à deviner pour un attaquant.

...

La longueur maximale du mot de passe ne doit pas être définie trop bas, car cela empêchera les utilisateurs de créer des phrases 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ées comme faibles si elles ne contiennent que des caractères latins minuscules.

Le stockage est bon marché, pourquoi limiter la longueur du mot de passe. Même si vous cryptez le mot de passe au lieu de simplement le hacher, une chaîne de 64 caractères ne prendra pas beaucoup plus qu'une chaîne de 6 caractères pour crypter.

Il y a de fortes chances que le système bancaire superpose un système plus ancien, de sorte qu'ils n'ont pu laisser qu'une certaine quantité d'espace pour le mot de passe.

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

Tous les systèmes dorsaux de la banque fonctionnaient auparavant lorsque j'utilisais mon mot de passe de 20 caractères avec des caractères non alphanumériques, donc le support hérité ne peut pas en être la raison. Et même si c'était le cas, ils devraient toujours vous permettre d'avoir des mots de passe arbitraires, puis de créer un hachage qui correspond aux exigences des systèmes hérités. Mieux encore, ils devraient réparer les anciens systèmes.

Une solution de carte à puce ne me conviendrait pas. J'ai déjà trop de cartes en l'état ... Je n'ai pas besoin d'un autre truc.

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

Essayez de ne pas imposer de limitation sauf si nécessaire. Soyez averti: cela pourrait et sera nécessaire dans de nombreux cas différents. La gestion des systèmes hérités 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éfivation de clé (KDF) que vous utiliserez (généralement PBKDF2, bcrypt, scrypt) prendront beaucoup de temps et de ressources. Exemple réel: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

Devrait-il y avoir une longueur maximale? C'est un sujet curieux en informatique en ce sens que les mots de passe plus longs sont généralement plus difficiles à retenir, et donc plus susceptibles d'être écrits (un GRAND non-non pour des raisons évidentes). Les mots de passe plus longs ont également tendance à être davantage oubliés, ce qui, bien que n'étant pas nécessairement un risque de sécurité, peut entraîner des tracas administratifs, une perte de productivité, etc. Les administrateurs qui pensent que ces problèmes sont urgents sont susceptibles d'imposer des longueurs maximales aux mots de passe.

Je crois personnellement sur cette question spécifique, à chaque utilisateur le sien. Si vous pensez que vous pouvez vous souvenir d'un mot de passe de 40 caractères, alors plus de pouvoir pour vous!

Cela dit, les mots de passe deviennent rapidement un mode de sécurité obsolète, les cartes à puce et l'authentification par certificat s'avèrent très difficiles, voire impossibles, à la force brute, comme vous l'avez déclaré, et seule une clé publique doit être stockée sur le serveur avec le privé. clé sur votre carte / ordinateur à tout moment.

Les mots de passe plus longs, ou phrases de passe, sont plus difficiles à déchiffrer simplement en fonction de leur longueur, et plus faciles à retenir que d'exiger un mot de passe complexe.

Il vaut probablement mieux opter pour une longueur minimale assez longue (10+), limitant la longueur inutile.

Les systèmes hérités (déjà mentionnés) ou l'interfaçage des systèmes externes du fournisseur peuvent nécessiter la limite de 8 caractères. Cela pourrait également être une tentative malavisée de sauver les utilisateurs d'eux-mêmes. Le limiter de cette manière entraînera un trop grand nombre de mots de passe pssw0rd1, pssw0rd2, etc. dans le système.

L'algorithme d'authentification utilisé est l'une des raisons pour lesquelles les mots de passe ne peuvent pas être hachés. Par exemple, certains algorithmes de résumé nécessitent une version en texte brut du mot de passe sur le serveur car le mécanisme d'authentification implique à la fois le client et le serveur d'effectuer les mêmes calculs sur le mot de passe entré (qui ne produira généralement pas la même sortie à chaque fois que le mot de passe est combiné avec un 'nonce' généré aléatoirement, qui est partagé entre les deux machines).

Cela peut souvent être renforcé car le résumé peut être partiellement calculé dans certains cas, mais pas toujours. Un meilleur moyen consiste à stocker le mot de passe avec un cryptage réversible - cela signifie alors que les sources de l'application doivent être protégées car elles contiendront la clé de cryptage.

Digst auth est là pour permettre l'authentification sur des canaux autrement non cryptés. Si vous utilisez SSL ou un autre cryptage à canal complet, il n'est pas nécessaire d'utiliser des mécanismes d'authentification condensée, ce qui signifie que les mots de passe peuvent être stockés hachés à la place (car les mots de passe peuvent être envoyés en texte clair sur le fil en toute sécurité (pour une valeur donnée de safe).

Seuls les mots de passe de 8 caractères semblent tout simplement 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 est comme une limite de 2000 lettres, ou quelque chose d'autre incroyablement élevé, mais uniquement pour limiter la taille de la base de données si cela pose un problème