Question:
Quels caractères ne dois-je pas autoriser dans les mots de passe?
Jonas
2011-02-10 23:08:48 UTC
view on stackexchange narkive permalink

Je prévois de développer un site Web qui exige que les utilisateurs enregistrent un nom d'utilisateur et un mot de passe. Lorsque je laisse l'utilisateur choisir un mot de passe, quels caractères dois-je autoriser les utilisateurs à avoir dans le mot de passe? y en a-t-il que je ne devrais pas à cause de problèmes de sécurité avec le protocole http ou le langage d'implémentation?

Je n'ai pas encore décidé d'un langage d'implémentation mais j'utiliserai Linux.

J'espère que vous utiliserez HTTPS. Pas HTTP.
Huit réponses:
#1
+43
user185
2011-02-10 23:21:14 UTC
view on stackexchange narkive permalink

Du point de vue de la sécurité / mise en œuvre, il ne devrait pas être nécessaire d'interdire les caractères en dehors de '\ 0' (qui est difficile à taper de toute façon). Plus vous barrez de caractères, plus l'espace de phase total des mots de passe possibles est petit et donc plus il est rapide de forcer les mots de passe. Bien sûr, la plupart des devinettes de mots de passe utilisent en fait des mots du dictionnaire plutôt que des recherches systématiques du domaine d'entrée ...

D'un point de vue utilisabilité , cependant, certains caractères ne sont pas tapés de la même manière manière sur différentes machines. Par exemple, j'ai deux ordinateurs différents ici où shift-3 produit # sur l'un et £ sur l'autre. Lorsque je tape un mot de passe, les deux apparaissent sous la forme «*», donc je ne sais pas si j'ai bien compris ou non. Certaines personnes pensent que cela pourrait suffisamment dérouter les gens pour commencer à refuser ces personnages. Je ne pense pas que cela en vaille la peine. La plupart des personnes réelles accèdent à de vrais services depuis un ou peut-être deux ordinateurs, et n'ont pas tendance à mettre beaucoup de caractères étendus dans leurs mots de passe.

@GrahamLee - était à mi-chemin et vous avez couvert tout ce que j'allais dire. Avoir un +1 :-)
http://xkcd.com/327/
@symcbean: "il ne devrait pas y avoir", pas "il n'y a aucune chance que vous vous trompiez" ;-)
Peut-être qu'il est utile d'avoir un avertissement comme * vous avez des caractères dans votre mot de passe qui ne sont pas au même endroit sur chaque clavier. Êtes-vous sûr de vouloir continuer? * Mais vu strictement, cela ne laisse qu'une vingtaine de touches identiques sur la plupart des claviers (sans compter Dvorak et autres).
Assurez-vous également que vous échappez à `` '' lorsque vous le stockez dans une base de données SQL!
@Earlz Cette question concerne le ** mot de passe ** si vous le stockez en texte brut, vous le faites mal.
@Holy oh wow. Ouais, ne tient pas compte de ça, j'ai été stupide pour une seconde lol
Pourquoi refuseriez-vous même «\ 0»?
Parce qu'il est plus susceptible d'être géré de manière incorrecte par l'implémentation sous-jacente. Vous ne voulez pas commencer à tronquer les mots de passe simplement parce que quelque part dans les entrailles de votre runtime, ils sont convertis en chaînes C.
Si l'utilisateur utilise un gestionnaire de mots de passe (comme il le devrait), la question de la saisie du mot de passe devrait être sans objet ...
#2
+17
Thomas Pornin
2013-02-03 03:28:19 UTC
view on stackexchange narkive permalink

Il peut y avoir des problèmes avec les caractères non ASCII. Un mot de passe est une séquence de glyphes, mais le traitement du mot de passe (hachage) nécessitera une séquence de bits , il doit donc y avoir une manière déterministe de transformer les glyphes en bits. C'est tout le marais trouble des pages de codes. Même si vous vous en tenez à Unicode, des problèmes se posent:

  • Un seul caractère peut avoir plusieurs décompositions comme points de code. Par exemple, le caractère «é» (qui est très fréquent en français) peut être codé soit comme un point de code unique U + 00E9, soit comme la séquence U + 0065 U + 0301; les deux séquences sont censées être équivalentes. Que vous obteniez l'un ou l'autre dépend des conventions utilisées par le périphérique d'entrée.

  • Une chaîne Unicode est une séquence de points de code (qui sont entiers compris entre 0 et 1114110). Il existe plusieurs codages standard pour convertir une telle séquence en octets; les plus courants sont UTF-8, UTF-16 (big-endian), UTF-16 (little-endian), UTF-32 (big-endian) et UTF-32 (little-endian). Chacun de ces éléments peut commencer ou non par une BOM.

Par conséquent, un seul «é» peut être codé de manière significative en octets d'au moins vingt variantes distinctes, et c'est en s'en tenant à "Unicode grand public". Le encodage Latin-1, ou son équivalent Microsoft, est également répandu, alors faites-en un 21. Le codage utilisé par un logiciel donné peut dépendre de nombreux facteurs, y compris les paramètres régionaux. C'est gênant lorsque l'utilisateur ne peut plus se connecter à son ordinateur car il est passé de "Canadien - Anglais" à "Canadien - Français".

Expérimentalement , la plupart des problèmes de ce type sont évités en limitant les mots de passe à la plage de caractères ASCII imprimables (ceux avec des codes allant de 32 à 126 - personnellement, je le ferais évitez les espaces, alors faites que 33 à 126) et appliquez le codage mono-octet (pas de nomenclature, un caractère devient un octet). Étant donné que les mots de passe sont destinés à être tapés sur divers claviers sans retour visuel, la liste des caractères devrait être encore plus restreinte pour une utilisation optimale (je me bats quotidiennement avec des dispositions canadiennes où ce qui est écrit sur le clavier ne correspondent nécessairement à ce que la machine pense être, en particulier lorsqu'elle passe par une ou deux connexions RDP imbriquées; les caractères '<', '>' et '\' se déplacent le plus souvent). Avec juste des lettres (majuscules et minuscules) et des chiffres, tout ira bien.

Vous pourriez dire que l'utilisateur est responsable; il est libre d'utiliser tous les caractères qu'il souhaite tant qu'il s'occupe du problème de leur saisie. Mais ce n'est pas tenable en fin de compte: lorsque les utilisateurs ont des problèmes, ils appellent votre helpdesk, et vous devez assumer une partie de leurs erreurs.

Bon article, mais je n'éviterais certainement pas l'espace, utiliser des phrases comme mot de passe n'est en fait pas une mauvaise pratique (voir aussi http://www.codinghorror.com/blog/2005/07/passwords-vs-pass-phrases. html, mais n'utilisez évidemment pas de citations célèbres comme dans l'exemple :))
Pourquoi éviter les espaces? Peut-être que str. remplacez-les si vous pensez que cela peut causer des problèmes de compatibilité n'importe où, mais être incapable de créer des phrases de passe décentes me dérange vraiment. Personne n'a d'espace dans les mots de passe, c'est pourquoi je les utilise très fréquemment.
Sur un clavier typique, la barre d'espace émet un son distinctif, ce qui en fait une proie facile pour les surfeurs d'épaule.
On devrait probablement dire «si vous utilisez Unicode, alors comme toujours, il y a des problèmes» au lieu de «même si vous utilisez Unicode». C'est Unicode qui crée des problèmes (comme toujours!), Pas les pages de codes. La saisie du même mot de passe avec la même page de codes produit exactement les mêmes bits, de manière fiable. Ce n'est que Unicode qui gâche les choses. La saisie du même PW en utilisant une page de codes différente produira des bits différents. Il s'agit en fait d'un tout petit peu de _ sécurité supplémentaire_ (2-3 bits pour deviner la page de code) pour une attaque par dictionnaire. Cela rend également l'utilisation d'un PW espionné plus difficile (peut-être en cours d'exécution dans la limite d'échec de connexion en essayant des CP).
#3
+11
Justin Morgan
2011-02-13 02:03:01 UTC
view on stackexchange narkive permalink

Si vous générez des mots de passe aléatoires, c'est une bonne idée d'éviter les caractères qui peuvent être confondus pour les autres. Par exemple (en ignorant les symboles):

  • Minuscules: l, o
  • Majuscules: I, O
  • Nombres: 1, 0
+1 Imaginez maintenant que vous organisez une cérémonie de signature de clé CA et que votre imprimante d'étiquettes donne l'impression que 1 et l sont indiscernables.
N'utilisent-ils pas simplement des post-it sur les moniteurs pour les mots de passe des clés principales?
#4
+6
Antony
2011-02-21 07:12:20 UTC
view on stackexchange narkive permalink

En plus d'autoriser tous les caractères, pensez à avoir une longueur maximale très généreuse dans le champ du mot de passe pour aider les personnes qui adoptent l'approche par mot de passe pour les mots de passe.

L'expression "mon mot de passe est entièrement en minuscules" est en fait une phrase de passe assez forte en raison de sa longueur.

#5
+2
Stephen Touset
2013-02-03 10:25:52 UTC
view on stackexchange narkive permalink

Vous ne devez interdire aucun caractère. Vous pouvez éviter que les mots de passe ne comportent moins de 6 caractères. Ensuite, vous devez utiliser bcrypt pour hacher le mot de passe.

Je m'opposerais avec véhémence à un système autorisant les retours de mots de passe.
Bonne chance pour obtenir un ASCII LF à partir d'un formulaire Web.
#6
  0
Konstantin Boyandin
2013-02-03 07:42:05 UTC
view on stackexchange narkive permalink

Je pense qu'à moins qu'un «clavier virtuel» ou un outil similaire soit disponible, qui produirait des caractères de manière uniforme, nous n'avons que des caractères alphanumériques. L'emplacement de tout le reste peut différer sur différents claviers. Si un utilisateur devait accéder au service depuis un autre emplacement, cela pourrait conduire à le verrouiller efficacement hors service.

Je suggérerais d'utiliser le clavier virtuel comme moyen d'envoyer exactement les mêmes représentations de caractères (cela a déjà été dit à propos d'Unicode ci-dessus) de la même manière quel que soit le système / clavier / tout ce qui est utilisé. Ainsi, il ne sera pas nécessaire d'exclure tout caractère qui pourrait être saisi sur n'importe quel mot-clé.

#7
  0
Tonny
2014-02-08 05:30:30 UTC
view on stackexchange narkive permalink

Il y a quelques caractères qui peuvent causer des problèmes:

*,? et%: comme ils sont souvent utilisés comme caractères génériques, ils peuvent confondre le langage de programmation sous-jacent.

Tab, Return, NewLine, Vertical Tab, Escape: ces caractères spéciaux peuvent solliciter un comportement étrange de votre langage de programmation OU du navigateur utilisé par le client. (Si le client utilise plusieurs navigateurs différents, il est tout à fait possible que l'un autorise la saisie de ceux-ci et pas un autre navigateur. Verrouiller efficacement le client de son compte sur ce navigateur.)

\ est souvent traité comme un caractère d'échappement qui donne au caractère qui suit une signification particulière.
Par exemple "\ n" est une nouvelle ligne dans de nombreux cas. "\ t" est tab.
Si votre langage de programmation (ou le navigateur du client) fait cela, vous êtes de retour à la possibilité de recevoir les caractères que j'ai mentionnés ci-dessus.
Il est donc probablement préférable de désactiver \ complètement juste pour être en sécurité.

Je suis désolé pour le vote négatif, mais il y a une raison à cela: les problèmes dans le langage de programmation sous-jacent ne sont * jamais * une raison pour interdire l'utilisation de caractères. C'est à cela que servent mysql_real_escape_string, ou mieux, les requêtes paramétrées. Les données utilisateur ne devraient jamais être interprétées comme étant du code exécutable, si cela se produit, vous aurez des problèmes beaucoup plus importants que le simple stockage des mots de passe. Les astérisques, les points d'interrogation, les signes de pourcentage et les contre-obliques sont des caractères parfaitement fins que j'utilise et que je souhaite continuer à utiliser dans mes mots de passe. D'ailleurs, ne les avons-nous pas hachés avant le stockage?
@Luc L'utilisation de `\ 0` à l'intérieur d'une chaîne risque de troncature silencieuse en C et ses dérivés, donc interdire cela semble raisonnable.`\ r`,` \ n` et `\ t` souffrent de problèmes d'entrée.Pour faire bonne mesure, j'étendrais cela à tous les caractères de contrôle (code ASCII <32)
@CodesInChaos Caractères de contrôle oui, ceux-ci n'ont pas de représentation visuelle et ne se produisent donc pas dans les mots de passe normaux.Le littéral `\ 0` (donc ASCII 92 et ASCII 48, pas ASCII 0) devrait également être parfaitement bien car il ne doit pas être interprété mais utilisé littéralement, mais je pense que vous voulez dire ASCII 0, auquel cas c'est un caractère de contrôle etJe suis d'accord.
#8
-7
OhBrian
2011-02-14 06:33:18 UTC
view on stackexchange narkive permalink

Si vous autorisez les caractères alphanumériques majuscules et minuscules et définissez la longueur minimale du mot de passe à huit caractères, vous devriez être d'accord. Autoriser d'autres personnages pose des problèmes avec différents claviers.

Si quelqu'un implémentait cela, je n'utiliserais pas son site car aucun de mes mots de passe ne fonctionnerait.
Ceci est très peu sûr et facilement craquable. Si vous vous limitez aux caractères supérieurs et inférieurs, votre longueur minimale doit être de 17.
@this.josh Longueur minimale de 17? Très bien, voici un md5sum d'un mot de passe de 8 caractères composé uniquement de lettres: `124c6ffa6d57c5909e7a403293aed173`. Généré en utilisant `echo -n secret | md5sum ». Puisque c'est moins que la racine carrée de la force que vous avez dite est le "minimum" il y a plus de 2 ans, je pense que ce ne doit pas poser de problème de craquer sur un gpu de base (en utilisant hashcat ou barswf ou quelque chose). Bonne chance. (Honnêtement, je pense que c'est faisable, mais md5 ne devrait de toute façon pas être utilisé pour le stockage des mots de passe. Pourtant, je me demande si quelqu'un peut le comprendre.)
@Luc pour le mot de passe dans {{A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z}, {a..z}} { {A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z}, {a..z}} {{A..Z }, {a..z}} {{A..Z}, {a..z}}; faire echo -n $ mot de passe | md5sum >> arc-en-ciel; echo $ mot de passe >> arc-en-ciel; terminé; echo "Tables arc-en-ciel à 8 caractères uniquement pour md5, grep simplement pour md5 et obtention du mot de passe, pas de GPU requis"
@this.josh faites-le, alors.
@Luc `pzNraRqZ` (je sais que c'est presque 3 ans plus tard)
@Kade Nice.Puis-je demander combien d'efforts cela a demandé?Par exemple, quelle est la configuration système requise et combien de temps cela a-t-il pris?


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