Quelles sont les meilleures règles à suivre pour quels caractères pour permettre un mot de passe?

Question

Sans penser à tout ce que je veux juste dire que je dois permettre à chaque caractère. Il se haché dans tous les cas, et je ne veux pas limiter les gens qui veulent créer des mots de passe.

Cependant, penser à plus, il y a beaucoup de personnages que je ne sais pas quel effet qu'ils auraient sur les choses. caractères étrangers, symboles ascii, etc. pour nommer un couple.

J'ai essayé de Google, mais je ne peux trouver aucune norme définitive pour ce que les gens font. Même la plupart des organisations professionnelles ne semblent pas savoir. Il semble être une pratique courante pour de nombreux sites de rejeter des caractères spéciaux tout à fait, ce qui est tout simplement ridicule et pas ce que je veux faire.

Quoi qu'il en soit, y at-il des recommandations standard pour les longueurs, les caractères autorisés, et ainsi de suite?

Je ne sais pas si ça compte, mais je vais utiliser ASP.NET w / C #

Answer 1

Tout caractère ASCII imprimable, non-espaces (entre 33 et 126 inclus) sont généralement autorisés dans les mots de passe. De nombreux professionnels de la sécurité (et SO) commenters avisent l'utilisation d'un mot de passe à la place d'un mot de passe , de sorte que vous auriez à permettre à des espaces. L'argument est que, en raison de leur longueur, et que des phrases ne sont pas dans un dictionnaire, sont plus difficiles phrases de passe à craquer que les mots de passe. (Un mot de passe peut aussi être plus facile de se rappeler, de sorte qu'un utilisateur légitime ne doit pas le garder écrit sur un post-it directement sur leur écran.)

Certains générateurs de mots de passe forts utilisent un hachage, donc je mettrais une limite très élevée sur la longueur (512 ou 1024) juste pour être inclus. générateurs de mot de passe aujourd'hui donnent souvent des chaînes de caractères 32-128, mais qui sait ce que les tables de hachage sera utilisé dans les prochaines années.

Answer 2

Les caractères non-ASCII font certainement les choses plus difficiles quand il vient d'entrer le mot de passe sur des périphériques limitées (mobiles, consoles, etc) - mais généralement pas impossible. On peut dire que si l'utilisateur veut faire cela, vous devriez les laisser. Il est assez facile de faire une chose raisonnable et cohérente - encode en UTF-8 avant de hashing, par exemple. Vous ne seriez en difficulté si un périphérique d'entrée a envoyé les caractères en tant que composition (par exemple e + accent aigu au lieu de « e aiguë ») - mais je pense que wouldn t se produire dans la vie réelle. (Vous pouvez vous décomposez tout, mais ce serait beaucoup de mal pour aller à un cas limite.)

Je limiterai à imprimables caractères, cependant. Mettre les onglets, etc dans feeds forme un mot de passe vraiment avoir des ennuis.

Answer 3

pas un expert, mais je déteste quand les personnages je choisis et non qui sont rejetés bizarre. Donc, je pense que je suis d'accord avec votre tube digestif.

Answer 4

Réponse courte: permettre autant que le système le soutien qu'il peut prendre en charge. De nos jours, il n'y a vraiment aucune excuse pour ne pas utiliser le support complet unicode pour la saisie de texte, et qui comprend des mots de passe. Je ne pense pas que vous devez vous soucier des problèmes avec des personnages aussi longtemps qu'ils sont traités littéralement (mais je ne suis pas un pro dans ce domaine - méfiez-vous de l'injection sql).

J'ai une bête noire contre les sites qui imposent des restrictions sur les mots de passe ... tout type de restriction . J'aime les sites qui vous dira la force de votre mot de passe est et recommanderiez-vous le rendre plus fort, mais de forcer un utilisateur à taper au moins 8 caractères, ou d'exiger des lettres et des chiffres, etc., est simplement frustrant.

Si vous avez besoin d'avoir une taille maximale du champ (par exemple pour le stockage dans une base de données) essayer de le rendre assez grand pour tout ce que les gens taper à la main. Il n'y a vraiment pas une telle chose comme un champ de mot de passe trop grand car il y a toujours la possibilité d'utiliser un système automatisé, généré mot de passe fort, mais 64 à 128 caractères serait certainement suffire.

Answer 5

Fondamentalement, la plupart de la classe de caractères unicode devraient être autorisés. Ne sautez contrôler certains caractères (par exemple 0-31 dehors de l'espace), la marque d'ordre d'octet (0xfffe et oxfeff). De plus, vous voulez d'abord canoniser la représentation pour se débarrasser des problèmes causés par des représentations différentes. Vous pouvez émettre des avertissements bien pour les caractères qui semblent être trop difficile d'entrer, mais les utilisateurs se prémunir contre eux-mêmes.

Answer 6

Rappelez-vous: Lorsque vous stockez des mots de passe, les mots de passe doivent être chiffrés avec un algorithme à sens unique comme md5 de SHA1. Étant donné que ces algorithmes donnent toujours des nombres hexadécimaux, vous n'avez pas besoin de vous soucier des injections SQL ou quelque chose comme ça.

Alors, aussi longtemps que vous pouvez ou md5 sha1 un caractère, il faut l'accepter.

Answer 7

Si vous parlez d'empêcher un type SQL injection d'attaques, il est sans doute une meilleure idée pour vous assurer que votre code fait ce qu'il est censé faire, plutôt que de compter sur la restriction de l'entrée de sorte que le problème devient plus facile.

Pour les caractères non-ascii, je ne vois pas cela comme un problème plus difficile si votre entrée peut être correctement représentée comme une chaîne binaire (et non comme text ), qui est ensuite transmis à votre fonction de hachage ou générateur de clé, etc.

Answer 8

Ajouter un autre vote pour « permettre à l'utilisateur inclut tous et des personnages qui leur interface leur permet d'entrer ». Je ne rejettera pas même les caractères de tabulation ou de contrôle. Votre logiciel a la capacité d'accepter les chaînes d'octets arbitraires et les hachage, donc accepter des chaînes d'octets arbitraires comme les mots de passe. Pour ce faire, sinon réduit l'espace qui un attaquant doit rechercher dans une force brute ou attaque par dictionnaire.

(Bien sûr, même si vous faites tout permettre, 99% des utilisateurs toujours utiliser le nom de leur animal de compagnie comme mot de passe ...)

Answer 9

Finalement, vous pourriez avoir à imprimer le mot de passe clair dans un e-mail envoyé à confirmlation vos utilisateurs.

PS: pourrait envisager également encodant les problèmes dans l'e-mail, si ce n'est pas ascii standard, il est possible qu'un utilisateur ne recevra pas l'e-mail dans le format approprié ou lire ne peuvent tout simplement pas sur un autre système (par exemple, les caractères japonais.) en raison de polices ne sont pas installées.

Tout cela pèse dans les caractères ascii "imprimables" RANGE.