Question:
Pourquoi certains sites Web et programmes restreignent-ils les caractéristiques des mots de passe?
TheLQ
2011-01-10 03:31:26 UTC
view on stackexchange narkive permalink

Il y a des sites Web et même des programmes que j'utilise qui ont des restrictions de mot de passe ridicules. De nombreux forums, par exemple, limitent les mots de passe à environ 32 caractères. D'autres appliquent un jeu de caractères restreint.

Qu'est-ce qui pousserait un développeur à mettre en place de telles restrictions? Tant que vous faites le hachage initial d'un mot de passe sur le client, il n'y a aucune charge sur le serveur pour avoir à calculer le hachage d'énormes mots de passe générés automatiquement. Il ne semble y avoir aucun avantage à utiliser de telles restrictions

Étant donné que ma première question a manqué la cible, je donne une réponse distincte. La raison principale est que des limites sont requises. Bien que la préoccupation concernant l'espace de stockage et la charge marginale du calcul du hachage d'un bloc de données de longueur arbitraire soit exacte, il y a quelques problèmes.
Vous ne faites pas le hachage initial côté client. Si vous le faisiez, cela signifierait qu'un mauvais client pourrait simplement utiliser le hachage comme mot de passe, réduisant ainsi la force du mot de passe quelle que soit la taille de votre hachage :)
@Bill Je pensais plus à sécuriser le mot de passe lorsque https n'est pas disponible, puis à ajouter votre sel sur le serveur. Mais c'est hors sujet.
Cinq réponses:
#1
+21
Jakob Borg
2011-01-10 07:20:08 UTC
view on stackexchange narkive permalink

Je pense que la raison est la même que pour toute autre validation d'entrée; pour vous assurer qu'il ne pose aucun problème pendant le traitement et le stockage. Maintenant, pour les mots de passe, c'est bien sûr complètement erroné car ils devraient être hachés et donc ni stockés ni vraiment traités en texte clair.

Je considérerais ces limitations comme une indication que les développeurs ne savent pas ce qu'ils font en matière de sécurité, et vont probablement stocker le mot de passe en clair. Reste loin.

+1, mes pensées exactement. Cependant, il est également possible qu'ils chiffrent symétriquement le mot de passe (au lieu de le hacher), auquel cas il serait toujours limité, par une taille de champ arbitraire longue mais pas assez longue. En outre, les limitations sur les caractères sont également une tentative malavisée de simplifier les comparaisons.
Le cryptage symétrique du mot de passe est le plus souvent un signe de rester loin de quelque part. Oui, il y a des moments où c'est nécessaire ou même une bonne façon de procéder, mais ils sont rares.
@Bill, oh je suis d'accord. Juste en soulignant qu'il y a des moments où ce n'est pas haché, et pourtant ont toujours la restriction. De plus, les mots de passe cryptés symétriques ne sont pas aussi mauvais que le texte brut, mais c'est (généralement, comme vous l'avez dit parfois où c'est vrai) un bon signe que les développeurs sont mal orientés.
#2
+11
D.W.
2011-01-10 10:19:16 UTC
view on stackexchange narkive permalink

Je vais aller avec: les mêmes vieilles raisons pour lesquelles les gens font des choses étranges.

  • Parce que cela semblait être une bonne idée à l'époque. Les développeurs peuvent être bien intentionnés mais mal informés. Il n'est pas nécessaire de limiter la longueur du mot de passe, mais peut-être que les développeurs ne le savent pas. Peut-être que les développeurs n'y ont même pas pensé.

  • Parce que c'était plus facile que les alternatives. Peut-être qu'ils utilisent une API qui ne peut pas gérer mots de passe de longueur arbitraire; cela pourrait faciliter la simple limitation de la longueur du mot de passe plutôt que l'utilisation d'une meilleure API. Peut-être qu'ils ont des failles d'injection SQL dans leur base de données, et plutôt que de coder les choses correctement pour éviter la faille d'injection SQL, il est plus facile de simplement mettre sur liste noire certains caractères (par exemple, interdire aux utilisateurs d'inclure des guillemets simples dans leurs mots de passe). Peut-être pour une raison quelconque, il était plus facile d'utiliser un tableau de longueur fixe qu'une chaîne de longueur variable. Qui sait.

Conclusion: il n'y a pas vraiment de justification pour de telles limites. Je suis sûr que nous sommes habitués au fait que les logiciels disponibles dans le commerce contiennent souvent toutes sortes de défauts de conception étranges. Ça arrive. C'est une réalité de la vie. C'est une conséquence du fait que "assez bien" est beaucoup moins cher que "parfait".

Mais aucune raison d'autoriser des mots de passe très longs. Il existe tellement d'alternatives utiles qui offrent plus de sécurité, moins de risques d'erreurs, etc.
#3
+11
Thomas Pornin
2011-01-10 20:28:25 UTC
view on stackexchange narkive permalink

Une raison rationnelle pour limiter la longueur du mot de passe et le jeu de caractères possible est d'inciter l'utilisateur à appliquer des techniques de gestion de mot de passe appropriées. En termes simples, si un mot de passe est énorme ou plein de caractères étranges, cela augmente la probabilité que l'utilisateur écrive le mot de passe sur un morceau de papier (traditionnellement collé sous le clavier) et / ou réutilise le même mot de passe dans plusieurs systèmes .

Conceptuellement, la manière dont l'utilisateur gère ses propres mots de passe relève de sa responsabilité, et non de l'activité du site Web. Mais, dans la pratique, les utilisateurs n'ont aucune idée de la sécurité et ne peuvent pas s'ennuyer avec tout ce qui n'a pas de rétribution immédiate (en particulier lorsque les utilisateurs sont des clients potentiels ). C'est donc au site Web d'essayer de faire ce qu'il peut pour protéger l'utilisateur.

Notez que je ne prétends pas qu'essayer d'appliquer une bonne gestion des mots de passe est la raison pour laquelle un site donné limite la longueur du mot de passe; c'est juste une raison pour laquelle je envisagerais une limitation de longueur de mot de passe sur mon propre site (si je devais gérer un site Web avec des mots de passe utilisateur).

Une autre justification pour un jeu de caractères autorisé limité est de promouvoir l'interopérabilité: de préférence, l'utilisateur doit pouvoir saisir son mot de passe sur une large gamme de périphériques d'entrée. Les caractères non-ASCII ne sont pas bons pour tout ce qui ressemble à un clavier américain (il est possible de taper des lettres non-ASCII sur un clavier américain, je le fais tout le temps, mais les méthodes varient en fonction du système d'exploitation et de la configuration, et le font ne fonctionne pas bien avec la saisie à l'aveugle comme c'est le cas avec la saisie de mot de passe). Les smartphones ont des restrictions encore plus importantes. Là encore, l'interopérabilité est (à mon avis) une bonne raison pour appliquer un jeu de caractères limité, mais de nombreux sites Web auront une telle restriction pour de mauvaises raisons (par exemple, pour que le mot de passe puisse être transféré négligemment dans un SQL demande sans échappement de chaîne appropriée, ce qui ne peut être décrit que comme une ingénierie bâclée).

Il y a de bonnes raisons d'encourager ou même d'imposer des mots de passe forts, mais je pense que neuf fois sur dix, ce qui se passe, c'est que les gens inventent un mot de passe fort, puis * écrivez-le sur un post-it *. Un mot de passe plus faible qu'ils ont ensuite mémorisé serait plus sûr.
@Shadur Je ne suis pas nécessairement d'accord. Bien qu'il soit moins sûr d'écrire un mot de passe que de le mémoriser, il n'est pas toujours possible d'acquérir de tels mots de passe écrits. Dans les contextes de haute sécurité, cela peut être vrai, mais pour les sites Web publics avec une énorme base d'utilisateurs, il est moins probable qu'un tel mot de passe soit recherché et volé. Son mot de passe faible est pire qu'un mot de passe écrit.
* En termes simples, si un mot de passe est énorme ou plein de caractères étranges, cela augmente la probabilité que l'utilisateur écrive le mot de passe sur un morceau de papier (traditionnellement collé sous le clavier) et / ou réutilise le même mot de passe dans plusieurssystèmes. * - (Presque) tous mes mots de passe sont de longs hachages ASCII spécifiques au site (que je n'ai pas notés mais générés quand j'en ai besoin).Imposer des restrictions m'empêche d'utiliser ces mots de passe sûrs.
#4
+3
Rory Alsop
2011-01-10 07:06:29 UTC
view on stackexchange narkive permalink

Je pensais que nous avions une question comme celle-ci mais soit mon search-fu est faible ce soir, soit il était sur un autre site.

Fondamentalement, dans la plupart des applications ou bases de données, il est logique de définir des limites utiles en entrée cordes. Cela vous permet d'arrêter la saisie une fois que la limite est atteinte (ce qui peut éviter les débordements, etc.) et vous permet également de prévoir les performances du code.

Vous pouvez également avoir besoin d'un stockage temporaire lors de la validation des mots de passe avant qu'ils ne soient hachés - encore une fois, permettant une entrée arbitrairement longue peut causer des problèmes.

Pourquoi 32? Un chiffre raisonnable pour la majorité des objectifs - l'entropie en 32 caractères est énorme. Bien sûr, dans certains environnements, cela ne sera pas suffisant, mais pour beaucoup d'entre eux, un cert ou un deuxième facteur (comme un jeton) peut être plus approprié de toute façon.

Bien que je convienne qu'il devrait y avoir des limites pour empêcher les gens de générer 10000 monstres de personnages, se limiter à 32 caractères et bloquer certains personnages ne sert à rien. À moins que vous ne soyez sur un site extrêmement actif, 100 de tous les caractères (y compris unicode) ajoutent peu de frais de calcul.
Je pense que cette réponse est circulaire. Le questionneur demande, "pourquoi y a-t-il des limites?". Vous répondez: "Parce qu'il est logique d'avoir des limites." Mais cela soulève simplement la question: "Pourquoi est-il logique d'avoir des limites?". Personnellement, je doute fort que les développeurs aient longuement pesé les alternatives et, après une profonde réflexion, aient décidé qu'une limite de 32 caractères est idéale et supérieure à toutes les alternatives. Je soupçonne qu'il est plus probable que les développeurs se soient davantage concentrés sur d'autres choses et qu'une limite de 32 caractères est principalement un accident.
Je suis tout à fait d'accord que ce n'est presque certainement pas un chiffre calculé. Ce n'est pas ce que je voulais dire. Vous ne voudriez absolument pas que les gens aient à entrer des mots de passe très longs - au-dessus de 30, cela n'a aucun sens d'avoir un mot de passe car vous vous laissez simplement ouvert à des erreurs de frappe, etc. Pour plus de sécurité, utilisez quelque chose de plus adapté au travail, comme un certificat ou un jeton, comme je l'ai mentionné. Cela a beaucoup plus de sens que de taper un mot de passe de 200 caractères par exemple.
@Rory, mais pourquoi serait-il sensé de mettre * une * limite sur la longueur du mot de passe? tout est haché à la même longueur, et si un utilisateur VEUT se punir pour obtenir «plus» de sécurité, pourquoi pas? N'oubliez pas qu'il ne le saisit peut-être pas - il existe de nombreux outils côté client (par exemple, PassSafe) qui le font pour vous.
@AviD - ma réflexion porte sur les étapes qui se produisent avant le hachage, vous devez gérer la chaîne de manière contrôlée. D'accord avec vous sur PassSafe cependant - je l'utilise pour conserver certaines informations d'identification de connexion là où l'application n'autorise pas les certificats ou les jetons.
Cela peut être pertinent pour par exemple Applications C ++, mais dans la plupart des applications - .NET, Java, divers langages de script - une `String` est juste une chaîne, et à part la charger avec 2 Go de longueur de données, cela ne devrait pas avoir d'importance. Mais, je réalise où vous allez - 60000 personnages est ridicule et inutile. 32 caractères pourraient être la même logique, mais beaucoup moins conservatrice ...
#5
+1
ygjb
2011-01-10 07:05:30 UTC
view on stackexchange narkive permalink

Étant donné que ma première question a raté la note, je donne une réponse distincte. La raison principale est que des limites sont requises. Bien que l'inquiétude concernant l'espace de stockage et la quantité de données soit exacte, il y a quelques problèmes.

Premièrement, si vous lisez ma réponse originale ci-dessous, vous verrez que l'une des recommandations est le hachage itératif (c.-à-d. Pbkdf) . Cela nécessite un grand nombre d'itérations pour être vraiment efficace. Si un utilisateur est capable de soumettre une grande chaîne, le coût du calcul de cette valeur de hachage itérative devient rapidement plus cher que prévu pour une simple fonction d'authentification.

Toute tâche coûteuse en calcul sur un serveur, en particulier une qui est explicitement disponible pour un utilisateur non authentifié, est soumis à des abus de la part d'un utilisateur malveillant pour effectuer une attaque par déni de service.

Deuxièmement, en implémentant un mot de passe de longueur fixe, il offre la possibilité de résilier prématurément si un une longue demande est soumise. Si les paramètres de la demande sont en dehors de la longueur attendue, il est simple d'émettre un message d'erreur et de fermer la connexion.


La raison pour laquelle les exigences de complexité des mots de passe sont appliquées sur de nombreux sites est d'empêcher les utilisateurs de choisir un mot de passe faible. Il existe de nombreux exemples dans l'histoire récente qui montrent que la plupart des utilisateurs choisiront des mots de passe faibles, faciles à saisir et faciles à retenir plutôt que des mots de passe complexes. Lorsque cela se produit, le propriétaire du site s'expose à des risques, car les utilisateurs blâmeront invariablement le site si un mot de passe est volé ou piraté, et quel que soit le résultat qui pourrait avoir pour le site et l'utilisateur concerné.

En implémentant des exigences de mot de passe strictes, cela réduit la probabilité qu'un attaquant puisse facilement deviner le mot de passe. Les mots de passe doivent également être protégés contre deux chemins d'attaque différents. La première, les attaques en ligne, nécessite qu'un développeur de site ait une politique qui empêchera les attaques par force brute de réussir. Ceci est accompli en exigeant qu'un utilisateur sélectionne un mot de passe suffisamment long et complexe, et en limitant le nombre de tentatives de connexion infructueuses avant de ralentir (c.-à-d. Verrouillages temporaires, captchas, etc.) ou d'arrêter les tentatives de connexion (verrouillages permanents, réinitialisation obligatoire du mot de passe, confirmations de compte , etc).

La deuxième attaque est une attaque hors ligne, où un attaquant va acquérir une copie d'une base de données de mots de passe, et tenter d'utiliser une table arc-en-ciel ou un cracker de mot de passe hors ligne pour pirater plusieurs comptes. Ce type d'attaque est évité en utilisant un algorithme de hachage puissant en conjonction avec un sel par utilisateur, et de préférence un ressassement de style pbkdf2 ou bcrypt / scrypt pour augmenter le coût de calcul du cracking hors ligne.

En fin de compte, les deux ces techniques échouent si les sites n'encouragent pas les utilisateurs à sélectionner un mot de passe unique pour leurs différents comptes. De nombreux utilisateurs sélectionneront les mêmes mots de passe pour plusieurs comptes, et lorsque ce mot de passe est exposé, en particulier avec leur compte de messagerie, il est possible qu'un attaquant utilise ces informations d'identification sur un autre service. Pour cette raison, il est préférable de générer des mots de passe uniques et forts pour chaque site, ou au moins différents groupes de sites et d'utiliser un gestionnaire de mots de passe sécurisé pour stocker tous les différents mots de passe.

Je pense que l'OP se demandait pourquoi le mot de passe était limité à une longueur aussi courte, plutôt que de le laisser entrer un mot de passe beaucoup plus long.
Hmm ... relisant la question, vous avez peut-être raison. Dans tous les cas, j'espère que ma réponse sera utile à quelqu'un;)
Balivernes. Les mots de passe longs ne seront pas une attaque DOS efficace. Je n'achète pas du tout cette réponse.
Je tiens également à souligner que limiter la longueur des mots de passe ou les caractères autorisés ne renforce pas les mots de passe; il * les affaiblit *, en limitant l'entropie. Et, les tables arc-en-ciel ne sont pas pertinentes ici; ils ne justifient pas les limites de mot de passe.
@D.W., La deuxième partie de sa réponse était le message original d'@ygjb's, quand il a mal interprété la question - et elle a été laissée là pour, espérons-le, aider quelqu'un de toute façon ...
Bien que je sois d'accord que les mots de passe longs ne contribueront pas à DOS, le hachage est extrêmement efficace, même avec des chaînes modérément longues. D'accord, le hachage «Guerre et Paix» pourrait causer un impact sur les performances, mais tout ce qui est raisonnable - même cent caractères - serait négligeable. De plus, en ce qui concerne le hachage répété (pbkdf) - après le premier hachage, vous aurez toujours la même longueur de sortie ...
le hachage en lui-même ne créera pas une condition de déni de service, mais des approches recommandées pour utiliser l'étirement de mot de passe de style pbkdf, scrypt ou bcrypt qui appellent au moins mille itérations de l'algorithme de hachage pour chaque authentification sur un ensemble de données arbitrairement volumineux , cela pourrait avoir un impact sérieux sur les performances du serveur. Dans ce cas, il est judicieux de définir une longueur maximale pour un mot de passe afin d'éviter un impact sur les performances du serveur.
@ygjb, si vous faites mille itérations de hachage pour chaque mot de passe, vous faites les mêmes mille itérations, quelle que soit la durée du mot de passe. Sauf pour la première itération, TOUTES les autres itérations fonctionnent sur la même quantité de données: la sortie de l'itération précédente. Par exemple. 512b (pour SHA-512). La longueur des données d'origine n'est pertinente que dans la première itération, après cela, vous ne traitez que des sorties de hachage (qui sont de longueur identique).
https://www.djangoproject.com/weblog/2013/sep/15/security/


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