Pourquoi le service client a-t-il déclaré que l'utilisation de symboles dans un mot de passe n'est pas sécurisée?
J'utilise un service en ligne que j'ai récemment dû réinitialiser mon mot de passe car je l'ai oublié. Quand je suis allé changer de mot de passe, je voulais en utiliser un avec un symbole !@£$%^&*(). Lorsque j'ai cliqué sur "confirmer le mot de passe", il m'a affiché "_Invaid Data" que j'ai finalement trouvé à cause du symbole. J'ai ensuite parlé au service client et je leur en ai parlé (ainsi que de remplacer "_Données invalides" par "Les mots de passe ne peuvent contenir que des lettres et des chiffres") et ils ont répondu en disant: "Désolé, les directives que nous avons mises en place sont pour la sécurité les mesures". (Voici à quoi ressemblait le message pour moi)
La question est pourquoi ont-ils dit qu'il n'est pas sûr d'autoriser les symboles dans les mots de passe lorsque les symboles le rendent plus sûr?
Pour m'assurer qu'ils ont une meilleure sécurité à l'avenir, je les ai informés et j'ai dit que si vous avez un mot de passe de 8 caractères avec des lettres et des chiffres uniquement, cela permettrait des combinaisons de 36^8=2,821,109,907,456, Y compris les 12 symboles (!@£$%^&*()_+), cela autoriserait 48^8=28,179,280,429,056 caractères de long, ce qui signifie qu'il existe une combinaison supplémentaire de 25,358,170,521,600 et ils transmettent maintenant ces informations à leur manager.
Ces "mesures de sécurité" ne sont pas pour votre sécurité, mais pour la leur.
Les symboles comme les tirets, les apostrophes, les signes de pourcentage, les astérisques, les barres obliques, les points, etc. sont utiles aux attaquants pour effectuer des attaques par "injection", comme l'injection SQL, l'injection XPath, l'injection de chemin de fichier, etc. En bloquant ces caractères, les propriétaires de sites espèrent qu'ils vous empêchent d'attaquer leurs serveurs.
Ils devraient probablement se concentrer davantage sur la gestion appropriée des données, comme l'utilisation interne de SQL paramétré et l'échappement de caractères spéciaux, mais c'est une mesure supplémentaire qui pourrait aider à servir de point d'arrêt en cas d'erreur de codage cachée dans leur site.
Je ne peux pas répondre définitivement "pourquoi" ils ont fait ça. Peut-être qu'ils avaient un auditeur de sécurité qui a dit "utiliser un jeu de caractères sur liste blanche pour l'entrée utilisateur et bloquer tous les symboles non alphanumériques." Peut-être que le package Web qu'ils ont acheté est venu avec cette restriction. Peut-être que leur vice-président de la sécurité a déclaré "ajouter des mesures visibles qui donnent à nos clients l'impression que nous prenons la sécurité au sérieux". Qui sait pourquoi?
La question est pourquoi ont-ils dit qu'il n'est pas sûr d'autoriser les symboles dans les mots de passe lorsque les symboles le rendent plus sûr?
Il est plus que probable que vous aviez affaire à un membre du service client qui n'a aucune idée de la raison pour laquelle certaines règles ont été mises en place et est parvenu à la conclusion, soit en utilisant cette excuse dans le passé et en obtenant des résultats, soit en inventant dans sa tête, que cela rendra la personne avec qui ils traitent ne pas remettre en question et simplement le faire.
Votre explication est juste sur la complexité d'un mot de passe qui devient beaucoup plus sûr en ajoutant des symboles ainsi que des lettres, des majuscules et des minuscules et des chiffres.
J'écrirais cela comme un agent du service client non formé essayant simplement de rendre le travail plus facile ou cette personne sait que la politique est défectueuse et veut simplement rendre cette conversation aussi courte que possible.
Parce qu'ils utilisent probablement l'assainissement d'entrée au lieu de les requêtes paramétrées et assainissement de sortie .
S'ils avaient paramétré des requêtes, ce ne serait pas un problème. S'ils savaient comment assainir leur sortie , ce ne serait pas un problème.
Plus que probablement, leur code est vulnérable à beaucoup d'autres choses, telles que contrebande basée sur unicode . Pour de nombreux "développeurs sécurisés", l'assainissement des entrées supprime simplement les apostrophes des entrées, ce qui est une approche incroyablement terrible.
Cela ne protégera pas contre la contrebande basée sur unicode et interférera avec les buts légitimes des apostrophes dans une base de données, tels que les noms des personnes. Imaginez que vous essayez de rechercher le nom de famille de quelqu'un dans une base de données, mais vous ne pouvez pas, car il y a une apostrophe. C'est stupide.
La solution correcte est la suivante: validation d'entrée (null> longueur> format> liste blanche) **> ** requêtes paramétrées > sortie assainissement (pour éviter XSS), qu'ils ne suivent probablement pas. Il n'y a aucune raison légitime d'exclure des données appropriées.
Acceptez votre analyse selon laquelle autoriser les symboles permet une plus grande sécurité, mais généralement ce n'est pas tant que ça. Surtout par rapport à l'utilisation de mots de passe légèrement plus longs (en supposant que le mot de passe est composé de symboles choisis au hasard). Utilisation de l'un des 95 caractères ascii imprimables:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|} ~
(quelques autres si vous comptez les caractères comme tabulation ou saut de ligne comme imprimables) un mot de passe à 8 caractères a 95 ^ 8 ~ 6,6 x 10 ^ 15 possibilités, alors qu'avec seulement des lettres et des chiffres (sensibles à la casse) un mot de passe à 8 caractères a 62 ^ 8 ~ 2,2 x 10 ^ 14 qui est environ 30 fois plus faible.
Cependant, un mot de passe à 9 caractères avec seulement des chiffres + minuscules + majuscules est deux fois plus fort qu'un mot de passe à 8 caractères autorisant les caractères spéciaux. Ainsi, à moins qu'il n'y ait des limites strictes sur la longueur d'un mot de passe (et vraiment il ne doit jamais y en avoir au moins pour des mots de passe de moins de quelques centaines de caractères), il est facile de passer à des mots de passe légèrement plus longs même avec un jeu de caractères limité.
Le plus gros problème de sécurité potentiel est qu'ils croient que l'autorisation de caractères spéciaux dans les mots de passe pourrait causer des problèmes dans leur application ou leur base de données. Il existe une raison légitime d'exclure les caractères non imprimables ASCII (par exemple, ASCII caractères de contrôle NUL (\0), retour arrière (\b), etc.) qui pourraient causer des problèmes, mais les applications bien conçues devraient être capables de gérer des caractères spéciaux réguliers comme ' ou - sans être vulnérable aux attaques par injection. Une application doit être capable de gérer ces types de caractères tels qu'ils apparaissent par exemple dans les noms avec des guillemets ou des tirets (par exemple, Conan O'Brien, Daniel Day-Lewis). De plus, comme les mots de passe ne doivent pas être enregistrés dans la base de données ou rendus à l'utilisateur et hachés immédiatement, ce qui permet d'imprimer ASCII les caractères spéciaux ne devraient pas avoir d'importance.
Certes, il existe des problèmes d'utilisation avec des caractères spéciaux non ASCII comme unicode, et pour des problèmes d'utilisation, il peut être judicieux d'interdire ces caractères ou de les normaliser de manière standard. Les fonctions de hachage attendent généralement une chaîne d'octets et des mots de passe avec des caractères spéciaux au-delà de ASCII peut être codé de différentes manières au niveau des octets (par exemple, UTF-8, UTF-7, UTF-16, ISO-8859-1). En outre, en plus des différents encodages (que vous pouvez conserver cohérents au niveau de l'application), vous devez également vous soucier des lettres identiques ayant des valeurs différentes en unicode. Par exemple, le caractère suivant Å est nicode 00C5 , mais ce caractère d'apparence identique est Å nicode 212B tandis que ce Å est en fait deux caractères - un ascii A avec un caractère de combinaison de nicode 030a ajoutant un encercler le A.
[~ # ~] modifier [~ # ~] : Je viens de remarquer que vous avez inscrit £ comme l'un de vos symboles communs. Malheureusement, ce n'est pas un standard ASCII symbole. En ISO-Latin-1, c'est l'octet A3. En UTF-8, ce sont les deux octets C2 A3. En UTF-7, ce sont les caractères ASCII +AKM-. En UTF-16, c'est 00 A3. Ces différents encodages signifient que votre fonction de hachage peut casser sur ce caractère si elle n'est pas gérée correctement. Certes, l'application devrait être capable de gérer l'encodage correctement, mais elle pourrait échouer sur certains sous-ensembles d'appareils. De plus, le personnage peut ne pas être disponible sur les claviers étrangers.
Il peut également y avoir des problèmes d'utilisation avec des caractères comme ' ou " que dans certaines applications/plates-formes peuvent être converties en citations intelligentes ‘’“” (bien que cela ne devrait jamais être fait dans un contexte de mot de passe).
Enfin, il existe une raison supplémentaire d'avoir des règles de mot de passe uniques - il est plus difficile pour les utilisateurs d'avoir un mot de passe mémorisé qui est réutilisé partout, ce qui est une pratique de sécurité horrible. Si le mot de passe "normal" de l'utilisateur ne répond pas aux règles uniques d'un site, alors lorsque son mot de passe normal est compromis sur un autre site aléatoire (qui dit stocke le mot de passe en texte clair), son compte n'est pas compromis sur le site avec l'unique règles.
Un peu extrait mais…
Disons que la mère de John reçoit un iPad pour Noël, elle a alors décidé de se connecter à sa banque en l'utilisant (plutôt que sur son ordinateur portable), mais ne peut pas trouver comment "taper" le symbole sur l'iPad. Elle demande donc à quelqu'un de lui montrer comment taper son mot de passe… ..
Réfléchissez maintenant aux problèmes d'assistance avec les clients ayant des mots de passe qu'ils ne savent pas "taper" sur leurs téléphones ou tablettes. Beaucoup d'appels d'assistance demandant la réinitialisation des mots de passe sont un problème de sécurité ainsi qu'un problème de coût.
Certains symboles peuvent ne pas être disponibles sur toutes les dispositions de clavier avec lesquelles vous interagissez. Cela vous empêcherait de vous connecter. Ce serait un problème de disponibilité, pas de sécurité.
Mais cela pourrait devenir un léger problème de sécurité si le symbole en question était disponible sur une disposition de clavier inconnue avec laquelle vous travaillez, mais pas dans une position familière. Dans ce cas, vous devrez peut-être trouver la bonne clé avant de la saisir dans le champ du mot de passe. Et (en particulier en l'absence de raccourcis clavier correspondants), vous pouvez éventuellement saisir des symboles dans un éditeur jusqu'à ce que le symbole que vous recherchez apparaisse. Lorsque vous vous arrêtez là, les personnes qui jettent un coup d'œil à votre éditeur (pendant que vous tapez ou plus tard parce que vous avez oublié de le fermer) connaissent au moins un des symboles contenus dans votre mot de passe.
Je dois être d'accord avec réponse d'Eddie Studer : même s'il y a une implication farfelue en matière de sécurité, il est probable que la personne qui vous en parle n'a aucune idée de la véritable raison de cette politique. Cela pourrait cependant être le problème de disponibilité que j'ai mentionné à l'avance, des utilisateurs ne pouvant pas se connecter, par exemple des cybercafés à l'étranger. Juste pour fournir une alternative aux problèmes d'injection exprimés par la plupart des autres réponses, même si celles-ci restent une raison très probable.
La plupart des gens ne peuvent pas taper de symboles sans ralentir et appuyer sur plusieurs touches à la fois, il y a donc une petite diminution de la sécurité si vous essayez de taper où vous pourriez être observé par un humain.
Votre argument est:
1. un mot de passe généré aléatoirement avec des symboles est plus fort qu'un mot de passe généré aléatoirement de la même longueur avec juste des lettres et des chiffres
2. donc autoriser les symboles dans les mots de passe les rend plus forts.
Ceci est valable si et seulement si les gens génèrent des mots de passe au hasard.
Comparons cependant un mot de passe créé avec l'algorithme suivant:
1. créer un mot de passe de longueur maximale - 1 avec des chiffres et des lettres
2. coller un symbole à la fin
En supposant que le nombre de symboles est inférieur au nombre de lettres et de chiffres, cela donnera un mot de passe plus faible qu'un mot de passe aléatoire composé uniquement de lettres et de chiffres, et fournira un faux sentiment de sécurité (`Je le mets à mot de passe $, pas à mot de passe !). Des arguments similaires peuvent être avancés pour générer des mots de passe en remplaçant les lettres par des symboles, etc.
On pourrait donc décider de ne pas autoriser les symboles, dans l'espoir que les gens choisiront d'utiliser un mot de passe aléatoire/plus long au lieu de pa$$Word. Bien sûr, cela "blesse" les utilisateurs qui souhaitent utiliser des mots de passe aléatoires avec des lettres + chiffres + symboles. Mais vous vous attendez à ce que ces utilisateurs soient suffisamment éduqués pour simplement ajouter quelques caractères supplémentaires, résultant en un mot de passe de force équivalente (en supposant que vous ne limitez pas la longueur).
Dans l'ensemble, juste parce que l'inclusion de symboles dans certains mots de passe augmente leur force, il ne s'ensuit pas que permettre aux gens d'utiliser des symboles augmentera la force du mot de passe moyen.
Hypothèse XML/Json:
Il se peut que le mot de passe soit envoyé à un service Web (espérons-le via un canal sécurisé) et ils ont constaté que des caractères spéciaux entraînaient un XML ou Json non valide. Au lieu d'échapper aux entités, ils ont restreint tous les symboles.
Un problème de sécurité est que si vous pouvez utiliser les caractères d'échappement " en XML et \" dans Json et le XML/Json est construit par concaténation de chaîne sans CDATA ou échappement, vous pouvez terminer avec une citation dans le champ même si vous avez vérifié la chaîne pour les guillemets simples et doubles.
Bien sûr, la solution consiste à éviter la concaténation de chaînes pour la génération de requêtes avec des paramètres externes.
P.S: Le mot de passe peut aussi aller à LDAP ouvrant la possibilité de injections LDAP
Alternativement à leur propre sécurité, imaginez que vous devez vous rappeler un mot de passe contenant des lettres majuscules et minuscules, des chiffres et des caractères spéciaux, la plupart des gens qui vont pour eux écriraient ce mot de passe sur un morceau de papier, éventuellement avec leur identifiant, qui serait considéré risque de sécurité élevé
Et si vous utilisez un mot de passe plus simple dont vous vous souvenez, il y a beaucoup moins de chances qu'il vous échappe.
.
Mais il est impossible de dire s'ils avaient une raison raisonnable ou si leur système ou leur gestion est défectueux sans être initié
J'évite les symboles dans les mots de passe car ils peuvent être difficiles à taper, en particulier sur les dispositions de clavier ou les appareils que je ne connais pas.
De plus, plus important encore, je ne fais pas souvent confiance à tous les développeurs de logiciels. Une fois, j'ai utilisé des mots de passe contenant des espaces. Certains services ont ensuite modifié leurs méthodes d'authentification afin de supprimer les espaces vides des mots de passe. Cela m'a empêché de me connecter.
Ma crainte est que des choses similaires puissent se produire avec d'autres symboles aussi, surtout si l'on considère les symboles non ASCII. Soit dit en passant, le fait que vos services à la clientèle découragent l'utilisation de symboles spéciaux est une forte indication du fait qu'ils ne devraient pas leur faire confiance et qu'ils peuvent faire des choses étranges (maintenant ou à l'avenir).
Après tout, si vous pensez aux chiffres, l'utilisation de symboles n'est pas très différente de l'ajout de quelques caractères à votre mot de passe alphanumérique:
- 100 symboles (tous ASCII caractères imprimables), longueur 8: 1008 combinaisons;
- 62 symboles (lettres et chiffres ASCII), longueur 9: 629 combinaisons, plus de 1008.
Utiliser plus de symboles aide, mais augmenter la longueur est bien mieux (kx croît plus vite que xk).
Mais les caractères limités sont assez courants pour le mot de passe et le nom d'utilisateur.
Dans l'informatique sécurisée, vous avez quelque chose appelé surface d'attaque, vulnérabilité et exploit. La fiabilité est distincte.
Oui, plus de personnage est plus aléatoire, mais vous avez également une plus grande surface d'attaque.
Vous pouvez créer des mots de passe suffisamment aléatoires avec un jeu de caractères limité. 36 ^ 8 = 2 821 109 907 456 est suffisamment aléatoire pour la plupart des besoins de sécurité. Sinon, augmentez-le à 10 ou 12 caractères. Vous ne pouvez qu'espérer qu'ils utilisent des caractères aléatoires. La vulnérabilité présente des mots de passe que vous pouvez deviner FistNameLastNaveYYMMDD où YYMMDD est la date de naissance.
Certains caractères Unicode se ressemblent. Vous pouvez créer un diacritique en tant que caractère distinct. Ces caractères ne sont pas les mêmes: grec Ο, latin O et cyrillique О.
Selon le jeu de caractères (page de codes) sur votre ordinateur, vous pouvez en fait obtenir différents mappages. L'idée est un ensemble sûr de caractères déterministes à travers les jeux de caractères.
Vous devez considérer le codage HTML, la compression sur le réseau, le salage, .... Qu'en est-il des caractères de contrôle?
Vous devez tracer la ligne quelque part et le fait est que vous n'avez pas besoin d'un grand jeu de caractères pour créer des mots de passe suffisamment aléatoires.
Il ne s'agit pas de programmeurs paresseux ou déficients. Il s'agit de fournir un code solide et fiable. Avec un jeu de caractères contrôlé peut mieux tester toutes les possibilités. Si quelque chose de bizarre se produit dans la transmission, il y a un ensemble de tests plus petit pour comprendre ce qui le brise.
Comme l'a dit @dr jimbob, vous utilisez le caractère non imprimable £ dans votre mot de passe !@£$%^&*(). Si vous supprimez le caractère non imprimable £ De votre mot de passe, il sera accepté quel que soit le service. Cela est dû au fait que le cryptage des mots de passe a été développé en c ou en Java au niveau de base pour maintenir le niveau élevé de sécurité.
Il est difficile d'amener les non-techniciens à leur faire comprendre les caractères non imprimables. Le responsable du service client vous a donc demandé d'utiliser les caractères alphanumériques simples et non les caractères spéciaux.
Essayez votre nouveau mot de passe avec !@$%^&*() veuillez changer le mot de passe après le test car il a été publié en ligne.
En termes simples, les caractères acceptés sont compris entre ASCII 32 à 126
Cette séquence particulière maintient simplement SHIFT et en tapant 1234567890. Je suppose donc qu'ils interdisent cette séquence particulière, car elle est simple pour un pirate informatique et beaucoup de gens le font. Par exemple, j'ai vu des gens utiliser QWERASDFZXCV pour un mot de passe qui n'est pas sûr parce que vous maintenez simplement la touche Maj enfoncée et que vous vous déplacez vers le bas sur le côté gauche du clavier.