2010-01-11 1 views
4

J'essaie de désinfecter toutes les données saisies en vérifiant que les données sont valides pour un champ particulier (par exemple, un nom ne peut pas contenir de caractères spéciaux/chiffres, etc.). Cependant, je ne sais pas quoi faire il arrive à un champ de mot de passe. Aurais-je même besoin de se soucier de la désinfection, car le mot de passe est simplement haché? Si l'utilisateur devait injecter quelque chose de malveillant via la boîte de texte du mot de passe, devrais-je prendre la peine de vérifier quelque chose de suspect? AFAIK, certains utilisateurs peuvent (devraient!) Avoir des caractères spéciaux tels que '<>', ce qui déclencherait normalement une alerte d'attaque potentielle. Devrais-je laisser le champ de mot de passe non identifié? Limiter l'entrée pour les mots de passe est un dernier recours pour moi, car je pense que les utilisateurs devraient utiliser toutes sortes de caractères dans leurs mots de passe.La désinfection d'entrée de mot de passe est-elle requise?

Merci

+4

Merci d'avoir réfléchi à cela et de faire la bonne chose (tm). Je suis si fatigué des sites Web qui vous limitent à un jeu de caractères spécifique ou à seulement 10 caractères ou moins. Et oui, je parle des sites bancaires du crétin. – NotMe

+0

lol, je sais ce que tu veux dire. Je n'ai pas encore vu une raison valable pour jamais handicaper le mot de passe d'un utilisateur. – XSL

+0

Il peut être utile de ne pas autoriser (même si cela ne supprime probablement pas) certains caractères. Par exemple, les caractères de contrôle, bien que certaines personnes utilisaient des caractères de tabulation dans les mots de passe UNIX (je crois). –

Répondre

3

Tant que vous l'êtes dans votre application Hashage, vous devriez être OK.

Un peu hors sujet étant donné que vous utilisez asp.net, mais une exception notable à ce serait si vous utilisez PHP et MySQL et de faire quelque chose comme ceci:

UPDATE users SET password = PASSWORD('$pwd') WHERE userid = $uid 

Dans ce cas, vous voulez pour assainir $ pwd en premier.

+0

Merci pour la réponse. J'utilise les contrôles d'adhésion ASP.NET pour faire tout cela, donc j'espère que je n'aurai pas à faire de changements de mot de passe manuels. Par conséquent, seul le hash sera stocké, ce qui signifie qu'il n'y a pas de menace. – XSL

+0

Dans PHP \ MySQL, pourquoi est-il nécessaire de nettoyer $ pwd s'il est hashé? – Ubeogesh

+1

@Ubeogesh $ pwd n'est pas haché. La fonction PASSWORD() dans MySQL le hache pour vous. Cela dit, je ne recommanderais pas d'utiliser la fonction PASSWORD de MySQL car il existe de meilleures alternatives pour le hachage des mots de passe disponibles. –

3

Si vous êtes concerné par les attaques par injection SQL, vous devez commencer à utiliser des requêtes paramétrées pour interagir avec votre base de données. Comme c'est une règle d'affaires pour déterminer ce qui est un caractère valide pour un mot de passe, je ne supprimerais rien tant que mon client ne le dirait pas.

Toutes les autres entrées doivent être nettoyées, car elles peuvent également être affichées sur la sortie de votre page et entraîner des attaques XSS.

+0

Salut. J'utilise les contrôles ASP.NET pour permettre aux utilisateurs d'enregistrer et de modifier les mots de passe, donc je crois que les requêtes sont automatiquement paramétrées. Je désinfecte manuellement les autres entrées avant l'événement UserCreated, mais l'entrée du mot de passe peut être codée, ce qui modifie le mot de passe réel. (Par exemple, XSL

+0

ligne de fond est: ce n'est pas grave, car il va toujours remplacer

+0

C'est un point juste et aussi longtemps que je travaille sur le projet, c'est bien. Je pense juste à long terme, si le projet change de main, d'autres développeurs peuvent commencer à interagir directement avec les mots de passe et ne pas les encoder dans la même méthode qui pourrait causer une certaine confusion. Bien que cela soit hautement improbable, j'aime pécher par excès de prudence. – XSL

Questions connexes