Restriction du jeu de caractères du mot de passe utilisateur

Question

Travail sur un système de connexion - le point où le client choisit son mot de passe pour l'accès au site. Au-delà de l'utilisation de RegEx pour s'assurer que le mot de passe est assez fort, normalement toutes les données qui seront stockées dans la base de données sont vérifiées par rapport à l'injection et un jeu de caractères raisonnablement restreint est appliqué sur tous les champs. Je ne veux pas vraiment un jeu de caractères particulièrement restrictif pour le mot de passe, car je pense que c'est un peu un anti-pattern sur la sécurité pour le contrôler trop.

Cependant, dans le cas du mot de passe, je vais avec ce hachage SHA-512 Salted pour insérer de toute façon qui soulève une poignée de questions:

• est-il un point quelconque à restreindre le caractère définir que le client peut utiliser dans le mot de passe - à savoir suis-je exposé à des vulnérabilités en dehors de l'injection qui, je suppose, seraient complètement contournées par le hachage? Il doit y avoir des aspects négatifs à une approche d'autorisation générale - je peux penser que dans l'avenir, ce qui est une combinaison innocente peut devenir dangereux - est-ce une réelle préoccupation, et y en a-t-il d'autres que je puisse avez manqué? Y a-t-il des caractères/chaînes qui doivent être rejetés - obtiendraient-ils de toute façon la protection ASP.NET native? Un peu plus subjectif peut-être, mais étant donné que c'est un hachage SHA-512 - est-il utile de restreindre la longueur maximale du mot de passe que l'utilisateur peut choisir (dans des limites raisonnables), en supposant qu'un mot de passe de taille significative/complexité pourrait déclencher un avertissement pour confirmer qu'ils veulent le définir.

Merci pour votre aide.

EDIT: Il s'agit d'une application Web ASP.NET accédant à une base de données MSSQL2008 à l'aide d'ADO.NET (pas LINQ/EF).

Answer 1

Il y a peu de raison de s'inquiéter des attaques d'insertion SQL sauf si vous insérez le mot de passe dans la base de données en texte brut (Danger, Will Robertson, Danger!) Et même si vous paramétrer la requête, il ne sera pas un problème. Vous devriez autoriser [a-zA-Z0-9] plus un ensemble de caractères spéciaux. Le seul caractère à limiter est probablement "<" qui déclenchera l'avertissement de validation ASP.net. Il existe un certain nombre d'outils amusants pour effectuer la vérification de la complexité du mot de passe du côté client. J'aime this one. Il fournit un retour instantané à l'utilisateur lors de la frappe.

Answer 2

D'un point de vue non anglais - il ne devrait y avoir aucune restriction sur le mot de passe.

Par exemple, pourquoi restreindre un locuteur japonais à l'utilisation du jeu de caractères US-ASCII? Et pourquoi un français ne devrait-il pas utiliser des caractères accentués? Etant donné que votre hachage est conservé correctement, il n'y a pas de raison technique de le restreindre.

Answer 3

Puisque le mot de passe est hashé, il sera stocké dans la base de données au format hexadécimal. Par conséquent, je ne vois pas l'intérêt de restreindre le type de caractères autorisés. Si je voulais utiliser une lettre chinoise dans mon mot de passe, je devrais être en mesure de le faire. Si j'ai installé une extension pour Firefox qui génère des octets aléatoires et les utilise pour mes mots de passe, je devrais être en mesure de le faire. La leçon ici est de ne pas limiter les mots de passe de vos utilisateurs.

Notez également que RegEx dispose d'un support Unicode capable de détecter si l'utilisateur a utilisé une lettre de n'importe quelle langue. Cela pourrait devenir utile lorsque vous validez la force du mot de passe.