Comment empêcher les correspondances de nom d'utilisateur et de mot de passe lors du changement d'un nom d'utilisateur?
Disons que j'ai un système où l'une des exigences de sécurité empêche les utilisateurs de choisir un mot de passe correspondant à leur nom d'utilisateur. Les noms d'utilisateur ne sont pas sensibles à la casse, mais les mots de passe le sont. Les mots de passe sont stockés par le serveur à l'aide d'une fonction de hachage sécurisée qui ne peut pas être inversée.
Lorsque le compte est créé, le nom d'utilisateur et le mot de passe sont initialement disponibles en texte brut sur le serveur pour comparaison. Nous pouvons les comparer en mémoire (sans tenir compte du cas) pour voir s'ils correspondent et demander à l'utilisateur de choisir un mot de passe différent s'ils le font. Une fois cette vérification satisfaite, le mot de passe est haché en toute sécurité pour le stockage tandis que le nom d'utilisateur est stocké en texte brut. Aucun problème pour répondre à l'exigence ici.
Lorsque l'utilisateur souhaite modifier son mot de passe, ou qu'il est en cours de modification pour lui, le serveur peut récupérer son enregistrement de nom d'utilisateur et le comparer à la valeur de mot de passe nouvellement choisie (en ignorant à nouveau la casse) pour voir s'il correspond. Pas de problème pour répondre aux exigences ici non plus.
Cependant, le système autorise également les changements de nom d'utilisateur. Au cours de ce processus de changement d'ID, l'utilisateur n'a pas nécessairement fourni son mot de passe en texte brut au serveur. Ils l'ont peut-être fait lors de leur authentification, mais le serveur ne conservera pas ce mot de passe en texte clair au cas où ils décideraient de changer leur nom d'utilisateur. Ainsi, le mot de passe en texte brut n'est pas disponible pour vérifier une correspondance avec la valeur du nom d'utilisateur nouvellement choisie.
Afin de répondre à notre exigence, le serveur peut utiliser la même fonction de hachage sécurisée pour hacher le nouveau nom d'utilisateur et le comparer au mot de passe haché enregistré. S'ils correspondent, le serveur peut demander à l'utilisateur de choisir un nom d'utilisateur différent. Cependant, comme le nom d'utilisateur n'est pas sensible à la casse, cette vérification peut échouer lorsqu'elle est vraisemblablement vraie. Si je soumets "PwdRsch1" comme nouveau choix de nom d'utilisateur et que mon mot de passe est "pwdrsch1", le système l'autorisera car les hachages ne correspondront pas. Je - ou pire, un attaquant - pourrais ensuite m'authentifier plus tard avec un nom d'utilisateur et un mot de passe correspondants "pwdrsch1".
Nous pourrions forcer le nom d'utilisateur en minuscules avant de le hacher et de le comparer au mot de passe, mais alors le scénario inverse est possible. Le nom d'utilisateur serait vérifié comme "pwdrsch1" par rapport à un mot de passe "PwdRsch1" et autorisé car ils ne correspondent pas. Mais plus tard, je peux m'authentifier avec succès avec un nom d'utilisateur et un mot de passe correspondants de "PwdRsch1".
Quelles options raisonnables ai-je pour réduire ce risque qu'un mot de passe corresponde à un nom d'utilisateur qui ne respecte pas la casse?
La seule façon raisonnable d'obtenir ce que vous voulez est de demander le mot de passe lorsqu'un utilisateur change de nom d'utilisateur. De cette façon, le serveur dispose toujours des informations nécessaires pour effectuer une comparaison précise entre le nom d'utilisateur et le mot de passe lors d'un changement et empêcher les correspondances.
Étant donné que les opérations sensibles - telles que la modification des mots de passe ou, dans votre cas, les noms d'utilisateur - devraient de toute façon nécessiter un mot de passe (pour limiter les dommages de XSS), cela ne devrait pas poser de problème.
Votre seule autre alternative consiste à essayer toutes les combinaisons de cas possibles, à les hacher et à les comparer au hachage stocké lorsqu'un utilisateur change de nom d'utilisateur.
Aller à contre-courant un peu - ne le faites pas faites attention si le nom d'utilisateur est changé en une chaîne "sensiblement similaire" comme mot de passe. Avertissez les utilisateurs du danger de sélectionner le même mot de passe et vérifiez la correspondance identique.
Peu importe le nombre de règles que vous mettez en place, si l'utilisateur est déterminé, il trouvera un moyen de les contourner. Si vous devez, demander le mot de passe lors du changement de nom d'utilisateur afin que vous puissiez les forcer sur le même boîtier, ou simplement le laisser passer et vérifier la prochaine fois qu'ils se connectent et forcer un changement d'utilisateur/passe ensuite.
Le niquement fois où tout cela est important est si vos utilisateurs sont soumis à une attaque ciblée. Si un script kiddie aléatoire (ou un autre opportuniste) accède à la liste des utilisateurs, il dispose d'outils bien plus sophistiqués pour briser ces mots de passe que d'essayer de faire correspondre le nom d'utilisateur. Il en va de même pour l'attaquant ciblé, mais il peut commencer par des choses simples qu'il peut saisir lui-même au clavier. Et si c'est une personne intelligente qui essaie de casser le mot de passe "PwdRsch1", allez-vous vraiment être sûr de vérifier les différences de casse? Qu'en est-il de "pwdr5ch1"? "PwdRsch2"? "1hcsRdwP"? Vous pouvez écrire des règles pour chacun de ces scénarios auxquels vous pouvez penser, mais il y en aura un que vous aurez oublié ou vous aurez tellement de mal à sélectionner un combo nom d'utilisateur/mot de passe qu'ils finiront simplement par utiliser "P4ssw0rd!" et en finir avec ça.
L'éducation est le niquement moyen d'amener vos utilisateurs à utiliser des mots de passe réellement sécurisés, et il y en aura toujours qui ne seront pas conformes.
Disons que le nom d'utilisateur contient 10 lettres. C'est 1024 combinaisons différentes de majuscules et minuscules. Vérifiez-les tous.
Ne stockez pas le hachage de mot de passe en minuscules. Ce 1024 peut vous sembler gênant, mais c'est la différence entre un jour et trois ans pour un attaquant.
Vous devez forcer les ID utilisateur et les mots de passe à provenir de différents ensembles. Dans les commentaires, il apparaît que l'ID utilisateur doit suivre le nom légal de l'utilisateur de manière formelle "John Smith" -> "jsmith" et "Jane Doe" -> "jdoe". Ensuite, si Jane épouse John et prend son nom, son identifiant doit changer en quelque chose comme "jsmith2"
Vous pouvez donc stipuler que le premier caractère d'un mot de passe doit être un symbole ou que le mot de passe doit contenir un symbole.
Si les ID utilisateur sont tronqués à 8 caractères, vous pouvez exiger que les mots de passe contiennent au moins 9 caractères.
Vous pouvez prendre le produit cartésien d'une liste de noms de famille et d'une liste de prénoms et l'utiliser comme liste noire pour les mots de passe. Si un employé a un nom qui ne figurait pas sur votre liste, ajoutez-le et, à mesure que les gens changent de mot de passe, le problème se résout automatiquement.
Ce n'est pas une réponse, je le mentionne seulement pour que les gens ne faites pas ça.
Vous pourriez décider qu'il serait judicieux de stocker, en plus du hachage normal de leur mot de passe sensible à la casse, un hachage de leur mot de passe converti en minuscules.
Cela résoudrait certainement votre problème - il vous suffit de mettre en minuscule le nom d'utilisateur que vous modifiez et de le comparer à ce hachage stocké du mot de passe en minuscule.
L'inconvénient évident est que cela va en partie à l'encontre de l'objectif d'un mot de passe haché en premier lieu: rendre les attaques sur votre liste de mots de passe beaucoup plus difficiles. Un attaquant ayant accès à vos listes de mots de passe hachés serait en mesure d'attaquer le hachage minuscule bien plus faible (2 ^ n fois plus faible) au lieu du hachage sensible à la casse.
Ainsi, les autres options mentionnées (demander le mot de passe au moment du changement; essayer toutes les permutations de casse si un administrateur le change, idéalement dans l'ordre le plus probable en premier) semblent de bien meilleurs paris.
Quelques bonnes réponses déjà, mais voici une autre façon d'aborder ce problème. Au lieu d'essayer de comparer le nouveau nom d'utilisateur au mot de passe existant, vous pouvez simplement forcer un changement de mot de passe chaque fois qu'un utilisateur change de nom d'utilisateur.
Naturellement, vous voudrez avertir les utilisateurs que la modification du nom d'utilisateur nécessitera de changer le mot de passe, mais vous pouvez ensuite facilement utiliser le processus existant pour vérifier les nouveaux mots de passe par rapport aux noms d'utilisateur.
La seule façon d'empêcher les utilisateurs de choisir des mots de passe stupides est de forcer les politiques de génération de mot de passe (par opposition au mot de passe tristement courant format politiques).
Maintenant, si vous n'avez pas autant d'autorité sur vos utilisateurs (la plupart des sites Web ne le font pas), vous devriez au moins leur dire de générer leurs mots de passe avec un gestionnaire de mots de passe (et de générer leur mot de passe principal avec dés =), et vous pourriez être en mesure de rendre difficile la désobéissance à cette politique:
Vous pouvez le faire en faisant en sorte que votre champ de mot de passe n'accepte pas la saisie au clavier, mais uniquement les données collées ou les données tapées par machine (je recommande de vérifier la vitesse à laquelle les caractères sont entrés). Ensuite, vous pouvez faire encadrer la boîte expliquant la politique de mot de passe en rouge ou quelque chose pour attirer leur attention sur elle.
Bien que la solution la plus judicieuse ait déjà été mentionnée et acceptée, à savoir demander le mot de passe lors du changement de nom d'utilisateur, car vous devriez le faire de toute façon. Une alternative consiste également à stocker le hachage du mot de passe en minuscules (avec un sel différent?) Et à comparer le nom d'utilisateur tout en minuscules à celui-ci.