Est-il dangereux d'afficher un message indiquant que le nom d'utilisateur / compte n'existe pas lors de la connexion?
Selon les OWASP Auth Guidelines , "Une application devrait répondre avec un message d'erreur générique, que l'ID utilisateur ou le mot de passe soit incorrect. Il ne devrait pas non plus donner d'indication sur l'état d'un compte existant."
Cependant, j'ai constaté que de nombreuses applications Web populaires violent cette directive en affichant un message indiquant que le compte n'existe pas.
Que se passe-t-il? Google, Microsoft et Slack font-ils quelque chose de peu sûr ou la directive OWASP est-elle inutile?
C'est une considération entre la sécurité et l'utilisabilité, et donc il n'y a pas vraiment de réponse à droite ici. Voici donc mon avis.
Si vous pouvez garder les noms d'utilisateur secrets, faites-le. Dans ce cas, il n'y a aucun moyen de déterminer si un nom d'utilisateur existe et la connexion réagit de la même manière, qu'un utilisateur existe ou non. Notez que cela signifie également prendre le même temps pour renvoyer un message d'erreur.
Ce comportement peut ne pas être possible. Par exemple, si les utilisateurs peuvent s'enregistrer et choisir leur propre nom d'utilisateur, vous devez les informer lorsqu'un nom d'utilisateur existe déjà dans le système. Si tel est le cas, rendez la connexion aussi facile à utiliser que possible en fournissant le message d'erreur le plus détaillé. Si quelqu'un peut déterminer si un utilisateur existe à l'aide de la fonction d'enregistrement, il ne sert à rien de le masquer lors de la connexion.
Ce n'est pas la seule directive OWASP qui n'est pas suivie par les gros joueurs. OWASP se concentre souvent sur la sécurité et ignore la convivialité. Cela peut être un choix de conception valide s'il est combiné avec une politique de mot de passe décente, une protection par force brute (verrouillage, captcha, ..), MFA, la surveillance des tentatives de connexion échouées, etc.
Tenez compte du fait que l'énumération des utilisateurs n'est pas seulement le problème de pouvoir deviner les comptes d'utilisateurs que vous pourrez ensuite utiliser par force brute pour l'authentification. Certains sites doivent protéger la vie privée de leurs utilisateurs (adultes, partis politiques, rencontres, ...). Si je veux vérifier si mon patron utilise un site Web pour adultes, je peux abuser d'une vulnérabilité d'énumération des utilisateurs pour savoir quels sites il utilise.
Vous ne pouvez tout simplement pas l'empêcher. (À moins que vous ne soyez prêt à sacrifier une grande quantité de convivialité.)
L'énumération des utilisateurs peut être indésirable et il y a en effet des implications potentielles pour la sécurité (par exemple, si un attaquant découvre qu'il existe un compte valide nommé admin auquel il pourrait essayer d'accéder). Mais pour les grands sites, c'est quelque chose que vous ne pouvez pas empêcher de se produire.
Même si vous ne révélez pas lors de la connexion qu'un utilisateur n'existe pas, vous devrez éventuellement avertir les nouveaux utilisateurs lorsqu'ils tenteront d'enregistrer un nom déjà pris ou avec un adresse e-mail déjà utilisée.
Il n'y a aucun moyen convivial de contourner cela:
La sécurité est relative. Il est légèrement plus sûr de ne pas donner d'informations sur l'existence ou non du compte. Mais cela ne signifie pas qu'il n'est pas sûr de divulguer ces informations. Il est juste moins sûr et très légèrement.
Cela est particulièrement vrai dans les exemples que vous donnez; il existe d'autres façons de trouver les noms de compte, il n'y a donc aucun avantage à essayer de cacher si le compte existe ou non.
Comme avec toute forme de sécurité par obscurité , masquer les noms de compte est un contrôle de sécurité faible, et d'autres contrôles sont nécessaires.
Je suis d'accord avec la réponse de @ Silver, mais je souhaite développer. Gardez à l'esprit le contexte; les directives OWASP sont conçues comme des règles de base pour les développeurs qui ne sont pas des experts en sécurité. Si une entreprise de développement de logiciels a une équipe d'architectes de sécurité de haut niveau, elle n'a pas besoin de suivre les règles de base aveuglément tant qu'elle comprend l'intention derrière les règles et atténue les risques par d'autres moyens.
Analogie: vous êtes censé changer l'huile de votre voiture tous les 3 mois ou 5000 km, mais les mécaniciens poussent souvent plus longtemps lorsqu'ils savent que leurs habitudes de conduite sont bonnes. Et c'est parfaitement ok.
En ce qui concerne les détails ici, je ne suis pas un expert en vulnération d'énumération des utilisateurs, et je ne suis pas au courant des raisons pour lesquelles Google et Microsoft ont pris les décisions qu'ils ont prises, mais je suppose qu'ils ont mis en place une limitation des taux et une liste noire pour empêcher à grande échelle attaques d'énumération des utilisateurs, et ont décidé autrement que la commodité de l'utilisateur vaut le risque supplémentaire.
Il est probablement trop difficile de dire qu'ils violent la directive OWASP, car pour les applications et les services comme Google, Microsoft, ils doivent être autant que possible "conformes aux utilisateurs".
De plus, ils ont tous ou proposent des protocoles 2FA.
Le but de ne pas divulguer l'identifiant d'utilisateur actif est d'empêcher l'énumération d'un grand nombre de comptes.
À strictement parler, vous pourriez vous protéger contre cela en autorisant les comptes en double, mais c'est une conception terrible et vous mènera à toutes sortes de problèmes.
Une autre façon de le faire est de assign utiliser un identifiant - en construire un qui n'est pas utilisé. Mais cette expérience d'utilisation est si mauvaise qu'elle n'en vaut peut-être pas la peine *.
La manière sensée de atténuer le risque est de mettre en œuvre une fonction anti-énumération - par exemple, un captcha de bonne qualité , pour ralentir toute tentative d'énumération. Ensuite, la conception est raisonnablement sûre.
Le risque résiduel est alors que vous laissez ouvert la vérification d'un compte de très grande valeur - par exemple, barack. [email protected]. Ensuite, vous atténuez ce risque en implémentant également un contrôle contre les tentatives de piratage de mot de passe, etc.
* Salzer and Shroeder, The Protection of Information in Computer Systems , Section IA3) h) Acceptabilité psychologique: Il est essentiel que l'interface humaine soit conçue pour être facile à utiliser, afin que les utilisateurs appliquent systématiquement et automatiquement correctement les mécanismes de protection. De plus, dans la mesure où l'image mentale de l'utilisateur de ses objectifs de protection correspond aux mécanismes qu'il doit utiliser, les erreurs seront minimisées. S'il doit traduire son image de ses besoins de protection dans un langage de spécifications radicalement différent, il fera des erreurs.