[security] Dois-je imposer une longueur maximale sur les mots de passe?



8 Answers

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 sécurité doit supposer le pire et s'attendre à ce que ce site stocke littéralement votre mot de passe (ie non haché, comme expliqué par epochwolf).

Dans ce cas: (a) évitez d'utiliser ce site comme la peste si possible [ils connaissent évidemment 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 .

Si vous développez un site qui accepte les mots de passe, NE METTEZ PAS de limite de mot de passe idiote, à moins que vous ne souhaitiez être goudronné avec le même pinceau.

[En interne, bien sûr, votre code peut traiter seulement les premiers 256/1028 / 2k / 4k (tout) octets comme "significatifs" pour éviter de croquer des mots de passe gigantesques.]

Question

Je peux comprendre qu'imposer une longueur minimale sur les mots de passe est très logique (pour sauver les utilisateurs d'eux-mêmes), mais ma banque exige que les mots de passe aient entre 6 et 8 caractères, et j'ai commencé à me demander ...

  • Cela ne faciliterait-il pas les attaques par force brute? (Mal)
  • Est-ce que cela implique que mon mot de passe est stocké non crypté? (Mal)

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?




Tout d'abord, ne supposez pas que les banques ont de bons professionnels de la sécurité informatique qui travaillent pour eux. Beaucoup ne le font pas .

Cela dit, la longueur maximale du mot de passe est sans valeur. Les utilisateurs doivent souvent créer un nouveau mot de passe (arguments sur l'intérêt d'utiliser différents mots de passe sur chaque site pour le moment), ce qui augmente la probabilité qu'ils les écrivent. Il augmente également considérablement la susceptibilité à l'attaque, par n'importe quel vecteur de la force brute à l'ingénierie sociale.




Une raison pour laquelle les mots de passe ne peuvent pas être hachés est l'algorithme d'authentification utilisé. Par exemple, certains algorithmes de résumé requièrent une version en clair du mot de passe sur le serveur car le mécanisme d'authentification implique que le client et le serveur exécutent les mêmes calculs sur le mot de passe entré (qui ne produit 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é, mais pas toujours. Une meilleure solution consiste à stocker le mot de passe avec un cryptage réversible, ce qui signifie que les sources de l'application doivent être protégées car elles contiennent 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 complet, il n'est pas nécessaire d'utiliser les mécanismes d'authentification digest, ce qui signifie que les mots de passe peuvent être stockés en hachage (les mots de passe peuvent être envoyés en clair sur le réseau (pour une valeur donnée).




Le stockage est bon marché, pourquoi limiter la longueur du mot de passe. Même si vous cryptez le mot de passe plutôt que de le hacher, une chaîne de 64 caractères ne prendra pas beaucoup plus d'une chaîne de 6 caractères à chiffrer.

Les chances sont que le système de la banque recouvre un système plus ancien, de sorte qu'il était seulement capable de laisser un certain espace pour le mot de passe.




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

Probablement préférable d'aller pour une longueur minimale assez longue (10+), en limitant la longueur inutile.




Je pense que vous avez 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 ouvre une variable de plus qu'un attaquant en force brute doit prendre en compte.

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




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 d'être haché. Le problème avec la troncature est que lorsque 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 pourriez avoir une période de transition où les deux longueurs sont hachées et vérifiées, mais cela nécessite plus de ressources.




Juste 8 caractères longs mots de passe sonnent tout simplement faux. S'il doit y avoir une limite, au moins 20 char est une meilleure idée.




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

Un autre processus de réflexion pourrait être que si un utilisateur est forcé d'utiliser un mot de passe court, il est plus susceptible d'inventer un charabia au hasard qu'un pseudo ou un slogan facilement deviné (par ses amis / sa famille). Cette approche n'est bien sûr efficace que si le frontend oblige à mélanger les nombres / lettres et rejette les mots de passe qui ont des mots du dictionnaire, y compris les mots écrits en l33t-speak.




Related