Juste pour être sûr, la connexion dans mon application actuelle ne stocke pas les paramètres transmis aux méthodes de connexion ou de réinitialisation du mot de passe. L'appel de journal a un paramètre facultatif qui contrôle cela, qui, lorsqu'il est défini sur true, remplace l'objet de paramètres stockés par [Redacted]. Bien sûr, je manque un peu de données, mais j'ai leurs adresses IP, et je préfère ne pas risquer d'obtenir quelque chose d'aussi sensible en texte clair.
Si vous voulez vraiment enregistrer ce genre de chose, je vous suggérerais, lors de la journalisation d'une tentative de connexion, de rechercher dans la base de données les utilisateurs dont le nom correspond à ce que vous avez dans le champ du nom d'utilisateur et de ne la stocker que si vous avez une correspondance. Sinon, vous ne stockez que comme "utilisateur inconnu". Vous pourriez avoir envie de vérifier si cette valeur contient ou non cette valeur, mais il y a toujours le risque d'obtenir des combinaisons comme [Utilisateur] [Mot de passe] et [UserPas] [épée], auquel cas vous pouvez vérifier par rapport à l'IP et en déduire que vous avez par inadvertance enregistré le début du mot de passe de quelqu'un en clair. Vous pouvez étendre cela au [utilisateur] [mot de passe] et au [mot de passe utilisateur] [??], ce qui est improbable mais possible. Dans ce cas, vous pouvez voir "connexion infructueuse par UserPassword" suivie de "connexion réussie par utilisateur" et en déduire tout.de mot de passe de l'utilisateur. En règle générale, pour être sûr, je dirais de ne pas enregistrer les noms d'utilisateurs à moins que la connexion soit réussie.
Modifier pour ajouter:
La plupart des arguments que les gens publient pour consigner le nom d'utilisateur des tentatives de connexion infructueuses sont, à mon avis, mieux gérés par d'autres méthodes.
Par exemple, il a été dit que lorsqu'un client demande "Pourquoi ne puis-je pas me connecter?", Les noms d'utilisateur enregistrés vous permettent de signaler des fautes de frappe. C’est vrai, mais le risque d’attraper des mots de passe ne vaut pas la peine. Pour ce faire, je redirigerais plutôt l'utilisateur vers le formulaire de connexion en cas d'échec, en mettant en surbrillance le champ du nom d'utilisateur et en le repeuplant avec ce qu'il aurait tapé pour qu'il puisse le voir par lui-même.
Un autre argument était que cela vous permettait d'identifier les tentatives de piratage; une chaîne d'échecs contre un nom d'utilisateur peut très bien être une tentative de forcer brutalement un mot de passe. Je le ferais en disposant une colonne "BadLogins" dans la table Utilisateurs, qui est incrémentée chaque fois qu'une connexion échoue avec un nom d'utilisateur correspondant à cet utilisateur et est réinitialisée à zéro si une connexion est réussie, après avoir indiqué à l'utilisateur "il y a eu x tentatives de connexion infructueuses depuis votre dernière connexion "et les aviser de la marche à suivre s’ils ne pensent pas que ces tentatives viennent d’eux. Si vous voulez être vraiment complet, vous pouvez avoir une autre colonne qui stocke la dernière valeur de la colonne BadLogins même après la connexion réussie, et / ou une colonne qui stocke la valeur la plus élevée de cette colonne, et / ou une colonne qui stocke le nombre total de connexions échouées de ce compte.