C'est une considération entre la sécurité et la convivialité, et il n'y a donc pas vraiment de bonne réponse ici. Voici donc mon avis.

Si vous pouvez garder les noms d'utilisateur secrets, alors 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'inscrire eux-mêmes et choisir leur propre nom d'utilisateur, vous devez les avertir lorsqu'un nom d'utilisateur existe déjà dans le système. Si tel est le cas, rendez la connexion aussi simple que possible en fournissant le message d'erreur le plus détaillé. Si quelqu'un peut déterminer si un utilisateur existe en utilisant la fonction d'enregistrement, il est inutile de le cacher lors de la connexion.

Ce n'est pas la seule ligne directrice de l'OWASP qui n'est pas suivie par les grands 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 contre la force brute (verrouillage, captcha, ..), une MFA, la surveillance des tentatives de connexion infructueuses, etc.

n'est pas seulement le problème de pouvoir deviner les comptes d'utilisateurs que vous pouvez plus tard 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 d'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 partie de la convivialité.)

L'énumération des utilisateurs peut être indésirable et il y a effectivement du potentiel implications 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 de enregistrez un nom déjà utilisé ou avec une adresse e-mail déjà utilisée .

Il n'y a pas de 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 veut pas dire qu'il est dangereux de donner ces informations. C'est juste moins sûr, et très légèrement.

Ceci est particulièrement vrai dans les exemples que vous donnez; il existe d'autres moyens de trouver des noms de compte, il n'y a donc aucun avantage à essayer de cacher si le compte existe ou non.

Comme pour toute forme de sécurité par l'obscurité, cacher le compte names 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 empiriques pour les développeurs qui ne sont pas des experts en sécurité. Si une société de développement de logiciels dispose d'une équipe d'architectes de sécurité de haut niveau, elle n'a pas besoin de suivre aveuglément les règles empiriques 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 5 000 km, mais les mécaniciens poussent souvent plus longtemps quand ils savent que leurs habitudes de conduite sont bonnes. Et c'est tout à fait correct.

En ce qui concerne les détails ici, je ne suis pas un expert des vulnités d'énumération d'utilisateurs, et je ne sais pas pourquoi Google et Microsoft ont pris les décisions qu'ils ont prises, mais je suppose ont mis en place une limitation de débit et une liste noire pour empêcher les attaques d'énumération d'utilisateurs à grande échelle, et ont par ailleurs décidé que la commodité de l'utilisateur vaut le risque supplémentaire.

Il est probablement trop difficile de dire qu'ils enfreignent la directive OWASP, car pour des applications et des services tels que Google, Microsoft, ils doivent être autant que possible "compatibles avec les utilisateurs".

De plus, ils ont tous ou proposez les protocoles 2FA.

Le but de ne pas divulguer l'identifiant de l'utilisateur actif est d'empêcher l'énumération d'un grand nombre de comptes.

À proprement parler, vous pouvez vous protéger contre cela en autorisant les comptes en double, mais c'est une conception terrible et vous conduira à toutes sortes de problèmes.

Une autre façon de faire est de attribuer aux utilisateurs un identifiant - en construisant un qui est inutilisé. Mais cette expérience d’utilisation est si médiocre qu’elle n’en vaut peut-être pas la peine *.

Le moyen judicieux pour atténuer le risque est de - fonction d'é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 ouverte la vérification d'un compte de très grande valeur - par exemple, barack .obama @ gmail.com. Ensuite, vous atténuez ce risque en implémentant également un contrôle contre les tentatives de piratage des mots de passe, etc.

* Salzer et Shroeder, La protection des informations dans les systèmes informatiques, section IA3 ) h) Acceptabilité psychologique: Il est essentiel que l'interface humaine soit conçue pour être facile à utiliser, afin que les utilisateurs appliquent correctement et systématiquement 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écification radicalement différent, il fera des erreurs.