Limiter le jeu de caractères du mot de passe utilisateur

Question

Travailler sur un système de connexion - le point où le client choisit son mot de passe pour accéder au site.

Au-delà de l’utilisation régulière de RegEx pour s’assurer que le mot de passe est suffisamment puissant, toutes les données qui aboutissent dans la base de données sont normalement vérifiées contre l’injection, etc., et un jeu de caractères raisonnablement restreint est appliqué à tous les champs. Je ne veux pas vraiment d'un jeu de caractères particulièrement restrictif pour le mot de passe, car je pense que c'est un peu un anti-motif sur la sécurité de le contrôler trop.

Cependant, dans le cas du mot de passe, je l'insérerai quand même avec un SHA-512 salé, ce qui soulèvera quelques questions:

• Y a-t-il un intérêt quelconque à restreindre le jeu de caractères que le client peut utiliser dans le mot de passe - c'est-à-dire que je suis 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 inconvénients à une approche tout-terrain - je peux penser au fait qu’à l'avenir, une combinaison innocente pourrait devenir dangereuse - s'agit-il d'un problème réel, et y en at-il d'autres? peut avoir manqué?

• Existe-t-il des caractères / chaînes qui doivent être rejetés - bénéficieraient-ils de toute façon de la protection native ASP.NET?

• Un peu plus subjectif peut-être, mais étant donné qu'il s'agit d'un hachage SHA-512 - y a-t-il lieu de limiter la longueur maximale du mot de passe que l'utilisateur peut choisir (dans des paramètres raisonnables), en supposant qu'un mot de passe d'une valeur significative taille / complexité peut émettre un avertissement confirmant qu’ils souhaitent le définir.

Merci de votre aide.

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

Answer 1

Il n’ya aucune raison de s’inquiéter des attaques par insertion SQL à moins d’insérer réellement le mot de passe dans la base de données en texte brut (Danger, Will Robertson, Danger!). Même dans ce cas, si vous paramétrez la requête, elle ne sera pas une problème. Vous devez autoriser [a-zA-Z0-9] plus un ensemble de caractères spéciaux. Le seul caractère à restreindre est probablement '& Lt;' qui déclenchera l'avertissement de validation ASP.net. Il existe de nombreux outils amusants permettant de vérifier la complexité du mot de passe côté client. J'aime celui-ci . Il fournit des informations instantanées à l'utilisateur au moment de la frappe.

Answer 2

D'un point de vue autre que l'anglais, le mot de passe ne devrait être soumis à aucune restriction.

Par exemple, pourquoi limiter un locuteur japonais à l’utilisation du jeu de caractères US-ASCII? Et pourquoi un francophone ne devrait-il pas utiliser des caractères accentués?

Étant donné que votre hachage est persisté correctement, il n'y a aucune raison technique de le restreindre.

Answer 3

Le mot de passe étant haché, il sera stocké dans la base de données au format décimal hexadécimal. Par conséquent, je ne vois aucun intérêt à limiter le type de caractères autorisés. Si je voulais utiliser une lettre chinoise dans mon mot de passe, je devrais pouvoir 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 pouvoir le faire. La leçon à tirer 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 peut devenir pratique lorsque vous validez la force du mot de passe.