Divulguer à l'utilisateur si le compte existe?
Quelqu'un m'a dit qu'il ne devrait pas être possible pour quelqu'un de détecter si une certaine adresse e-mail est utilisée par un utilisateur enregistré sur un site Web. Ainsi, par exemple, lorsque l'utilisateur demande de réinitialiser son mot de passe, vous devez dire "Mot de passe envoyé", que l'e-mail existe ou non dans la base de données. Sinon, les gens peuvent utiliser cette fonction pour vérifier qui est membre et également vérifier la validité des listes de spam, etc.
Mais j'ai remarqué que Facebook dit "E-mail déjà enregistré" si vous essayez d'enregistrer deux fois le même e-mail. Est-ce à dire que les conventions ont changé; qu'informer l'utilisateur est plus important que révéler des comptes?
C'est une tradition assez ancienne de ne pas dire aux gens si des connexions spécifiques existent ou non. C'est pourquoi les systèmes Unix ou Windows, lorsqu'ils demandent des informations d'identification d'utilisateur, répondront à toute erreur par un message générique "nom d'utilisateur ou mot de passe incorrect". L'idée vient d'une vision plutôt démodée des attaques: imaginer un méchant qui veut entrer dans un mainframe, et réussit à mettre la main sur un terminal série branché sur le système, ou peut-être une interface telnet sur une ligne de modem. Cet attaquant sera en position de attaque par dictionnaire en ligne : il essaiera de deviner une paire login + mot de passe qui lui donne accès. Les noms de connexion administratifs tels que "root" étaient généralement mieux protégés que les comptes d'utilisateurs normaux (l'utilisateur "root" était mieux à même de sélectionner des mots de passe forts, ou du moins c'était supposé) afin que les attaquants tentent de trouver des comptes d'utilisateurs normaux et, dans en particulier, les noms de compte d'utilisateur normal .
Regarder le film War Games (à partir de 1983) vous donne une bonne idée de la situation.
Notez le point critique: dans le scénario d'attaque ci-dessus, l'attaquant veut obtenir au moins un compte, mais n'a pas pu en obtenir un dans des conditions normales, ou même savoir qui a un compte.
C'est maintenant 2013, trois décennies après ce film. Nous avons des serveurs où tout le monde peut s'inscrire gratuitement et obtenir un compte. Obtenir un compte n'est donc plus le but d'un attaquant. Au lieu de cela, l'attaquant voudra accéder à des comptes spécifiques , avec des identités connues. Ce n'est pas la même situation. Le contexte a changé. Par conséquent, la vieille tradition n'est pas nécessairement applicable.
Quoi qu'il en soit, lorsqu'un utilisateur essaie de s'inscrire sur Facebook, il s'attend que le processus fonctionne. À ce stade, le processus peut échouer pour une seule raison plausible, qui est une adresse e-mail déjà utilisée. Il serait difficile de cacher ce fait à l'utilisateur ...
Si nous voulons "protéger" les adresses e-mail des utilisateurs, le processus d'inscription doit se dérouler ainsi:
- L'utilisateur entre son e-mail présumé.
- Un e-mail est envoyé à cette adresse, contenant un lien d'inscription unique; cependant, si l'e-mail est déjà enregistré, un e-mail est envoyé expliquant ce fait. Aucun indice n'est écrit sur la page Web de réponse pour savoir si l'e-mail existait déjà dans le système ou non.
- L'utilisateur s'inscrit en suivant le lien de l'email.
Un tel processus se doublerait d'un processus de vérification des e-mails, donc c'est plutôt bien. Cependant, il a une certaine latence (l'utilisateur doit sortir du site Web, ouvrir son lecteur de messagerie et attendre le courrier électronique entrant), cela peut donc être problématique pour les sites commerciaux (les utilisateurs ne sont pas patients et ils sont enclins à faire du shopping ailleurs s'ils trouvent le processus de paiement trop lourd). De plus, il doit y avoir des garde-corps pour éviter que ce système d'enregistrement ne soit utilisé abusivement dans une machine de spam.
Je pense que l'on peut dire que, pour les responsables de Facebook, rendre le processus d'inscription aussi fluide et rapide que possible est plus important que la confidentialité de l'utilisateur. Vraiment, qui aurait cette surprise?
Il pourrait y avoir des risques PII impliqués à considérer. Il est prudent de supposer que "tout le monde" a un compte Facebook, donc divulguer qu'un e-mail en particulier s'est enregistré n'est pas un problème.
Mais, prenez un autre service, comme "dépression-help.com" ou "it-burns-when-I-tinkle.net". Il serait difficile de communiquer au grand public qu'une personne/un e-mail particulier est inscrit sur le site.
De plus, pour les petits services avec une base d'utilisateurs intentionnellement petite, la divulgation des noms d'utilisateur peut fournir des informations supplémentaires à un attaquant qui pourrait compromettre des comptes comme ça certains films de 198 .
Pointe du chapeau à @ThomasPornin, mais je crois qu'il y a des cas, comme ceux que j'ai suggérés, qui valent la peine de prendre une décision éclairée de ne pas divulguer les noms de compte d'utilisateur/e-mails.
Il n'y a vraiment pas de moyen gracieux de résoudre ce problème qui puisse rendre tout le monde 100% heureux. Si vous forcez l'utilisation des adresses e-mail en tant que noms d'utilisateur, vous pouvez facilement déterminer si quelqu'un qui a une adresse e-mail donnée est un utilisateur (problème de confidentialité). Si vous autorisez des noms d'utilisateur arbitraires, vous ne pouvez vraiment pas vous déplacer en révélant éventuellement si un nom d'utilisateur donné est déjà utilisé, et tout ce que vous pouvez vraiment faire est de prendre des mesures pour ralentir un utilisateur qui essaie de découvrir des noms d'utilisateur valides.
Les enregistrements de nouveaux utilisateurs sont le problème le plus difficile à résoudre, car il est impossible de contourner le fait que vous devrez finalement gérer avec élégance une collision de nom d'utilisateur. Voici une option possible: Demandez à l'utilisateur d'entrer une adresse e-mail, un nom d'utilisateur proposé et le mot de passe souhaité. Lors de la soumission, validez que le mot de passe est acceptable et envoyez à l'utilisateur une URL de validation.
Si l'adresse e-mail est déjà utilisée, mais associée à un nom d'utilisateur différent, envoyez un e-mail à cet utilisateur, rappelez-lui qu'il possède déjà un compte et demandez-lui s'il souhaite réinitialiser le mot de passe.
Si l'adresse e-mail n'est pas déjà utilisée, mais que le nom d'utilisateur l'est, envoyez à l'utilisateur un message d'erreur lui indiquant qu'il doit choisir un autre nom d'utilisateur et qu'il doit attendre de plus en plus de temps entre chaque tentative.
Si l'adresse e-mail et le nom d'utilisateur sont tous les deux nouveaux, envoyez à l'utilisateur un lien de confirmation qui nécessite une nouvelle authentification avec le nouveau nom d'utilisateur et le nouveau mot de passe avant de le rendre officiel.
NE PAS permettre à deux utilisateurs d'avoir le même nom d'utilisateur en supposant que vous pouvez identifier l'un ou l'autre en fonction de leurs mots de passe. Entre autres choses, si deux utilisateurs peuvent partager le même nom d'utilisateur, cela signifie que vous ne pouvez jamais verrouiller le nom d'utilisateur en raison d'échecs de tentatives de connexion sans affecter les DEUX utilisateurs. Et à Dieu ne plaise, s'il arrive un jour de choisir le même mot de passe, tout l'enfer se déchaînera.
N'utilisez pas la même valeur pour le nom d'utilisateur et l'identité publique. Vous n'avez pas nécessairement à empêcher activement les utilisateurs d'entrer la même valeur pour les deux s'ils le souhaitent vraiment, mais la valeur par défaut devrait être d'autoriser les utilisateurs ( sur quelque chose comme un forum de messages, par exemple) pour avoir un surnom public qui n'a pas nécessairement quelque chose à voir avec le nom d'utilisateur avec lequel ils se connectent.
N'attribuez pas séquentiellement les ID utilisateur. Utilisez au moins 31, de préférence 62, des valeurs aléatoires de bits qui sont générées et vérifiées comme uniques au moment de l'enregistrement. La bonne chose à propos des valeurs de 31 et 62 bits est le fait qu'elles se traduisent parfaitement en chaînes de base36 à 6 et 12 caractères. Lors du débogage, il est beaucoup plus facile de se souvenir d'une chaîne de 6 ou 12 caractères de lettres minuscules et de chiffres qu'une valeur décimale de 6-17 chiffres. La partie la plus difficile est de répondre aux demandes qui spécifient un ID utilisateur non valide avec des réponses fausses, mais qui ne peuvent pas être facilement distinguées des réponses d'ID utilisateur réel par des moyens algorithmiques.
Rappelez-vous: vous ne pouvez pas et ne réussirez jamais à 100% à empêcher un attaquant de vérifier occasionnellement si un ID utilisateur ou un nom d'utilisateur donné est valide. Votre objectif est de le rendre aussi lent et coûteux que possible, sans surcharger excessivement vos vrais utilisateurs. Pour un analogue du monde réel, pensez aux codes de région DVD et Blu-Ray. À l'époque où un joueur coûtait 500 $ et plus, les codes de région étaient un moyen efficace d'empêcher presque tout le monde de lire des films achetés dans une autre région. Maintenant que vous pouvez acheter un lecteur Blu-Ray pour 80 $ et un sélecteur HDMI pour 20 $ et récupérer la monnaie, rien n'empêche un cinéphile d'acheter simplement deux ou trois lecteurs Blu-Ray (un par région souhaitée), empilables les et en les exécutant via le commutateur HDMI.
Pour les connexions de routine, soyez délibérément vague sur la raison pour laquelle CETTE tentative de connexion a échoué, mais soyez également franc sur les raisons possibles ... et donnez-leur les coordonnées concrètes de quelqu'un qui peut les aider. Gardez une trace des échecs de connexion et verrouillez le compte si trop de tentatives de connexion ont échoué.
Ne leur dites pas tout de suite que le compte vient d'être verrouillé ou est actuellement verrouillé ... mais n'hésitez pas à le mentionner comme l'une des raisons possibles pour lesquelles une tentative de connexion a échoué. Garder le fait qu'un compte POURRAIT être verrouillé d'un utilisateur tentant de se connecter ne fera rien pour votre sécurité.
Vous n'avez pas nécessairement à verrouiller un compte de manière semi-permanente en raison d'échecs de tentatives de connexion. Dans de nombreux cas, vous ne devriez probablement pas , car ALORS vous aurez créé une attaque pratique de déni de service. Si un compte a trop de tentatives de connexion infructueuses, vous POUVEZ faire un verrouillage "doux" pendant 1, 6 ou 24 heures, moment auquel le verrou se supprimera. C'est le un scénario IMHO où il est légitime de dire à un utilisateur de "réessayer plus tard".
Un exemple de message d'erreur qui peut s'afficher en cas d'échec d'une tentative de connexion:
Le nom d'utilisateur et/ou le mot de passe que vous avez entré n'ont pas été acceptés. Vous avez peut-être entré un nom d'utilisateur non valide, utilisé un mot de passe incorrect ou tenté de vous connecter avec un compte qui a été verrouillé en raison de tentatives de connexion infructueuses. Si le compte a été verrouillé, vous pouvez contacter _ __ pour obtenir de l'aide [ ou attendre _ heures pour le compte à déverrouiller par lui-même]. Veuillez noter que ce message d'erreur sera le même pour toutes les connexions ayant échoué, quelle qu'en soit la raison.
NE leur dites PAS "Quelque chose s'est mal passé, veuillez réessayer plus tard" à moins que le problème ne se répare littéralement par lui-même. Cela ne trompera pas un attaquant et ennuiera sérieusement les utilisateurs légitimes. C'est l'un de mes ultimes bêtes noires, et en haut de ma liste des "choses horribles que les développeurs font au nom du théâtre de la sécurité". En plus d'être incroyablement ennuyeux, si le compte de quelqu'un a été compromis, la DERNIÈRE chose que vous voulez qu'il fasse est d'attendre plus tard avant de le porter à l'attention de quelqu'un.
C'est un comportement Facebook standard que vous pouvez rechercher un compte si vous avez l'adresse e-mail correspondante. De nos jours, beaucoup de gens ont désactivé cette option, mais c'est toujours le lieu où Facebook se présente.
Lors de la modération du forum, j'ai fréquemment utilisé cette fonctionnalité pour recueillir des informations sur la question de savoir si un compte nouvellement enregistré est un compte enregistré d'un utilisateur interdit.
Les sites Web indiquant si les adresses e-mail ou les noms d'utilisateur sont réels sont un moyen d'attaquer l'anonymat. Je me souviens d'un cas où quelqu'un s'est réenregistré qui utilisait l'IP d'un nœud de sortie TOR. J'ai pu dire à la personne le nom de sa mère grâce aux informations qu'il a partagées sur Facebook. Le chemin vers l'information a traversé quatre cerceaux de surnoms associés les uns aux autres.
La divulgation d'informations comme celle-ci facilite le fonctionnement d'entreprises comme http://www.spokeo.com/ .
Lorsqu'il s'agit de protéger la confidentialité, vous devez également considérer toutes les données sensibles. Prenez un forum avec 1000 utilisateurs. Les utilisateurs publient des informations inoffensives sous un surnom. Un utilisateur connecté au forum avec une adresse e-mail associée à sa véritable identité.
Avec 1000 utilisateurs, il y a de fortes chances que je puisse identifier avec la stylométrie et divulguer des informations lequel des 1000 utilisateurs est la personne que je recherche. Si je réussis dans cette tâche, j'ai un surnom secret.
Je peux maintenant exécuter des recherches Google sur ce surnom et également rechercher [email protected] dans d'autres bases de données. J'ai également obtenu un échantillon de texte plus grand pour faciliter l'exécution de futures attaques de stylométrie.
Un attaquant au niveau gouvernemental qui souhaite trouver des dissidents a les ressources pour interroger un grand nombre de services Web afin de vérifier si certaines adresses e-mail existent et peut également investir dans de bons systèmes de stylométrie.
Si vous souhaitez protéger la confidentialité, il est logique de masquer les adresses e-mail enregistrées.