Il est possible de collecter un ensemble de noms d’utilisateur valides en interagissant avec le mécanisme d’authentification de l’application. Ce test sera utile pour les tests de force brute, dans lesquels le testeur vérifie s’il est possible de trouver le mot de passe correspondant, étant donné un nom d’utilisateur valide.
Souvent, les applications web révèlent si un nom d’utilisateur existe sur le système, soit à la suite d’une mauvaise configuration, soit par décision de conception. Par exemple, parfois, lorsque nous soumettons des identifiants incorrects, nous recevons un message indiquant que soit le nom d’utilisateur est présent sur le système, soit le mot de passe fourni est incorrect. Les informations obtenues peuvent être utilisées par un attaquant pour obtenir une liste d’utilisateurs sur le système. Ces informations peuvent être utilisées pour attaquer l’application web, par exemple, par une attaque par force brute ou par nom d’utilisateur et mot de passe par défaut.
Correction suggérée :
La boîte de dialogue « j’ai oublié mon e-mail » doit se comporter de la même manière, que l’adresse e-mail soit valide ou non.
N’informez pas les utilisateurs qu’un compte existe avec une adresse e-mail donnée lors de l’inscription ou du flux de récupération de mot de passe. Exigez l’adresse e-mail complète pour les demandes de « mot de passe oublié ».
En parcourant les discussions, ce problème est apparu plusieurs fois auparavant. Je pense que l’un des autres points importants est que nous avons une limitation de débit lors des tentatives de connexion :
Merci à vous deux. Je suis tombé sur ce bug de manière organique sur meta.discourse.org et j’ignorais l’existence de ce paramètre, mais il est bon de savoir que la correction est déjà codée et que le correctif devrait être très simple. Afin de satisfaire aux meilleures pratiques de l’OWASP, ce paramètre devrait toujours être activé. Je ne vois pas pourquoi un administrateur souhaiterait désactiver cela, car le faire représente une vulnérabilité de sécurité et de confidentialité totalement inutile qui viole explicitement les normes de meilleures pratiques de l’industrie. S’il existe une raison de conserver cette option pour les installations existantes que je ne peux pas comprendre, alors un avertissement devrait être ajouté pour indiquer que la configuration actuelle viole les meilleures pratiques standard de l’industrie et recommander la configuration conforme à la place.
Merci d’avoir partagé ce fil. @awesomerobot a le droit d’avoir son opinion, mais il défie aussi effrontément les meilleures pratiques standard de l’industrie et insiste sur le fait qu’un bug bien connu, souvent signalé et explicitement codifié n’est en quelque sorte « pas un bug », et je ne trouve pas son opinion très convaincante par rapport aux meilleures pratiques standard publiées de l’industrie.
À tout le moins, la valeur par défaut devrait refléter la configuration la plus sûre, et il devrait y avoir une indication pour signaler aux administrateurs novices que la désactivation de cette option constitue une vulnérabilité de sécurité et de confidentialité délibérée et inutile sur leur forum. Un lien vers l’entrée OWASP ou quelque chose de similaire.
Quelqu’un peut-il m’éclairer sur le scénario où il serait préférable de désactiver cette option ? Je ne sais vraiment pas pourquoi c’est un problème controversé et j’aimerais savoir si je manque un cas d’utilisation qui rend inutile le modèle de sécurité opt-in mis en œuvre avec ce paramètre. Si un tel scénario ne peut être suggéré, alors ce paramètre devrait toujours être activé et ne devrait donc pas être un paramètre du tout.
Je pense qu’actuellement, tout fonctionne comme prévu, nous ne pouvons donc pas vraiment qualifier cela de Bug. Cependant, nous réévaluons régulièrement nos paramètres par défaut et vous avez soulevé des points intéressants qui méritent d’être pris en considération.
Je vais transférer cela à UX pour que la conversation se poursuive là-bas.
Tout simplement… les gens ont du mal à se souvenir de l’adresse e-mail qu’ils ont utilisée pour créer un compte et contactent les administrateurs pour résoudre les problèmes.
Ceci est similaire à forcer la deuxième authentification ou longueur minimale du mot de passe — Je pense que la recommandation générale est de toujours exiger une deuxième authentification, et les recommandations de longueur minimale du mot de passe semblent maintenant être plus élevées que notre valeur par défaut actuelle pour les utilisateurs réguliers… mais il y a aussi un fossé entre les recommandations de sécurité et les compétences informatiques moyennes.
Je ne suis pas fortement opposé à la modification des valeurs par défaut, mais il convient de noter qu’elles peuvent avoir un impact sur la convivialité.
Cela me semble être le comportement par défaut de Discourse qui devrait suivre les meilleures pratiques – comme presque tous les autres sites.
Il semble que j’aie le paramètre approprié défini sur mon instance :
Si un compte correspond à x@example.com, vous devriez recevoir un e-mail avec des instructions sur la façon de réinitialiser votre mot de passe sous peu.
Merci à tous pour vos précieuses contributions et perspectives sur ce bug. Pour moi, c’est très simple et pas compliqué du tout : il existe un bug bien connu dans Discourse qui a été signalé à plusieurs reprises par des administrateurs et des professionnels de la sécurité comme moi, et il est traité comme une fonctionnalité plutôt que comme une vulnérabilité de sécurité : NIST : CWE-200 : Exposition d’informations sensibles à un acteur non autorisé.
Justifier cette configuration par défaut non sécurisée qui viole les meilleures pratiques standard de l’industrie en citant une situation hypothétique où un administrateur de forum est inondé de demandes d’utilisateurs concernant les e-mails qu’ils ont utilisés pour s’inscrire n’a pas de sens, car l’utilisation de la page “mot de passe oublié” ne nécessiterait pas cette interaction de l’administrateur, quelle que soit la configuration de ce paramètre : si le paramètre plus sécurisé et conforme aux normes est activé, l’utilisateur vérifierait simplement son ou ses e-mails dans le dialogue “mot de passe oublié” et verrait si cette adresse a reçu un e-mail de réinitialisation de mot de passe, exactement comme expliqué par le dialogue, et comme c’est courant dans toutes les applications web modernes, respectueuses de la vie privée et conformes aux normes. De plus, justifier cette violation en partant du principe que d’autres sites pourraient également violer les meilleures pratiques n’est pas un argument logique ou convaincant du point de vue de la sécurité et de la protection des données. J’ai du mal à comprendre pourquoi nous donnons aux administrateurs la “fonctionnalité” de rendre leur installation Discourse marginalement moins sécurisée et conforme aux normes, sans aucun avantage clair.
Néanmoins, j’ai fait le travail que vous m’avez prescrit @sam :
Google : n’autorise pas le dénombrement des utilisateurs.
YouTube : n’autorise pas le dénombrement des utilisateurs (car il utilise la connexion Google, et Google n’autorise pas le dénombrement des utilisateurs).
Instagram : autorise le dénombrement des utilisateurs (et en a fait les frais). Il s’agit d’un piratage différent de celui que j’ai mentionné pour Facebook.
Baidu : autorise le dénombrement des utilisateurs sur la page de réinitialisation de l’e-mail, et met en œuvre un captcha (et peut-être une limitation de débit ? Mon chinois est mauvais). Fait intéressant, le processus de récupération nécessite d’ouvrir un appel auprès de l’équipe d’administration, plutôt qu’un simple e-mail de récupération. Très typique du contrôle central du PCC.
Wikipedia : n’autorise pas le dénombrement des utilisateurs.
Yahoo : Autorise le dénombrement des utilisateurs via sa page de réinitialisation de mot de passe, mais met en œuvre une limitation de débit et un captcha. Je n’ai pas trouvé d’exemples de Yahoo ayant été pris dans des controverses ou ayant versé de l’argent à des pirates exploitant ce bug, mais il est vraiment difficile de rechercher Yahoo sur n’importe quel moteur de recherche pour des raisons évidentes.
Yandex : autorise le dénombrement des utilisateurs sur la page de connexion, met en œuvre un captcha et une question de sécurité sur la page de réinitialisation de l’e-mail.
Whatsapp : n’autorise pas le dénombrement des utilisateurs. La connexion PC se fait via les identifiants mobiles. Les identifiants mobiles sont liés à votre numéro de téléphone. Il n’y a pas de bouton de déconnexion, ni de page de connexion/réinitialisation d’e-mail.
XVideos : n’autorise pas le dénombrement des utilisateurs.
PornHub : n’autorise pas le dénombrement des utilisateurs.
Xnxx : n’autorise pas le dénombrement des utilisateurs. Le site principal n’a pas vraiment de page de connexion, et le site “gold” n’autorise pas le dénombrement des utilisateurs. J’ai trouvé une page de connexion obsolète sur la version mobile du site régulier, et elle n’a tout simplement pas de fonctionnalité “oublier mon e-mail” (et est également apparemment obsolète, au profit de leur site web “gold”).
Tik Tok : n’autorise pas le dénombrement des utilisateurs. Impose l’authentification multifacteur sur la page de réinitialisation du mot de passe.
(21. Reddit : N’autorise pas le dénombrement des utilisateurs. Ils sont conformes aux meilleures pratiques standard de l’industrie.)
Parmi les 15 principaux sites de cette liste, 8/15 NE permettent PAS le dénombrement des utilisateurs (ou 9/16 si l’on inclut Reddit, et en ajoutant discrètement 0,5 pour Facebook puisqu’il n’autorise que le dénombrement d’informations que l’utilisateur a délibérément approuvé à rendre publiques), et au moins 3/7 des sites de cette liste qui AUTORISENT le dénombrement des utilisateurs ont connu des événements de sécurité critiques en conséquence de cette décision.
Il est par ailleurs trivial de tester l’existence de comptes sur les fournisseurs d’identité par e-mail, donc il n’y a pas grand intérêt à les inclure dans la liste.
Aucune des autres plateformes de cette liste n’est un logiciel (potentiellement) auto-hébergé.
Il n’y a pas de plateforme Discourse centrale - les administrateurs de site sont libres de choisir eux-mêmes.
Cela dit, je serais d’accord pour inciter les administrateurs de site à choisir de bons paramètres par défaut.
Peut-être un bouton que les administrateurs peuvent actionner (j’hésite à suggérer de l’ajouter à l’assistant) pour resserrer facilement des paramètres comme celui-ci.
N’est-ce pas applicable à n’importe quel site avec une page d’inscription, pas seulement aux fournisseurs de services de messagerie ? Je vois votre point de vue sur la façon dont les pages d’inscription sont un vecteur potentiel de vulnérabilités similaires en matière de confidentialité et de données et doivent donc être protégées, mais c’est une partie différente du flux d’authentification de l’utilisateur que celle dont nous discutons dans ce sujet. Dans ce sujet, nous examinons spécifiquement les fuites du dialogue « J’ai oublié mon mot de passe ». Ne vous méprenez pas : les deux sont absolument importants, exigent une attention particulière et nécessitent des mesures d’atténuation afin de prévenir les vulnérabilités en matière de confidentialité et de données. Habituellement, pour les formulaires d’inscription, vous exigez un captcha, et pour les points d’accès « J’ai oublié mon mot de passe », vous voulez avoir la même réponse, qu’e-mail soit valide ou non. De nombreux sites sécurisent également le point d’accès « J’ai oublié mon mot de passe » avec un captcha. Les deux points d’accès doivent être limités en débit.
Je n’essayais certainement pas d’être trompeur. Je ne pense pas que il est acceptable de ne pas être conforme parce que d’autres sites ne le sont pas non plus soit une conclusion logiquement valable de toute façon, je remplissais simplement la demande de Sam et pour apaiser toutes les préoccupations qu’il pourrait avoir en fournissant la « preuve » qu’il recherchait en utilisant le lien qu’il a fourni.
J’encourage certainement la liberté des administrateurs, et je n’aime pas compliquer la vie des administrateurs ou des utilisateurs, mais je ne pense pas que les « avantages » de ce paramètre l’emportent sur les « inconvénients » dans un scénario quelconque, et il n’y a aucun cas où un administrateur voudrait réellement cette « fonctionnalité ». Tout comme nous ne permettons pas à un administrateur d’imposer une longueur maximale de mot de passe, nous ne devrions pas lui permettre de dégrader inutilement et marginalement la sécurité de son forum en autorisant cette vulnérabilité d’énumération sur le dialogue « J’ai oublié mon mot de passe ». Je pense que nous devrions simplement supprimer complètement l’option et obliger tout le monde à suivre la manière conforme aux normes. Honnêtement, je ne pense pas que la plupart des administrateurs le remarqueraient ou s’en soucieraient, mais cela rendrait un point d’accès public sur Internet quelque peu plus sûr sur toutes les installations Discourse. Si nous devons inclure le paramètre, alors il devrait être dans la position la plus sûre par défaut, et la position la moins sûre devrait être clairement délimitée afin que les administrateurs novices comprennent pourquoi elle n’est pas recommandée. Je pense que simplement refactoriser ce paramètre hors d’existence est la meilleure option cependant. Je serais heureux de soumettre une PR pour cela.
Je ne pense pas que l’on puisse considérer l’un ou l’autre dans le vide. Dans le processus d’inscription de Discourse, il y a un message « Cet e-mail est déjà pris » et il est difficile de voir comment faire cela différemment. Tant que cela existe, il est difficile de voir quel est le gros problème avec le message « Nous avons trouvé un compte qui correspond » spécifiquement.
Je suppose que cela ferait une différence dans un forum n’autorisant que l’authentification externe.
Ayant surmonté l’envie d’être en désaccord avec vous simplement à cause de votre style, je pense que sur le fond, vous avez raison dans la mesure où votre position est que l’option par défaut devrait être l’option la plus sécurisée, du moins lorsque l’authentification externe est utilisée. Je ne suis toujours pas d’accord qu’il n’y a aucune place pour l’option moins sécurisée (mon forum a le processus d’inscription par défaut de Discourse, donc je ne prévois pas de changer l’option de réinitialisation du mot de passe).
Soit dit en passant, j’ai ri du fait que vous laissiez le lecteur deviner par le contexte que XVideos et Xnxx (mais pas X) sont pornographiques, mais que vous preniez la peine d’expliquer qu’Amazon est un « site de commerce électronique ».
Il s’agissait de distinguer Amazon.com d’AWS. Et puisque vous demandez : AWS n’autorise pas l’énumération d’utilisateurs.
Je suis d’accord sur le fait que vous devez considérer toutes les étapes d’un flux d’authentification d’utilisateur et leur fonctionnement conjoint. C’est extrêmement important et l’une des sources les plus courantes de vulnérabilités de sécurité. Si ce bug similaire d’énumération d’e-mails sur la page d’inscription que vous avez mentionné n’est pas correctement atténué, il devrait absolument être corrigé, quel que soit le résultat de ce sujet. Ce serait un bug dans l’implémentation de hide_email_address_taken. La discussion de ce bug/cette omission potentiel devrait probablement avoir lieu dans un autre sujet (et probablement avec une balise bug).
Juste pour information, avec hide email address taken activé, ce message n’apparaît pas non plus lors de l’inscription (cela modifie également le message d’invitation lorsqu’un e-mail existant y est saisi).
Je pense que l’une des complications possibles pour simplement inverser la valeur par défaut est qu’elle inclut également la fonction « exiger un e-mail complet pour la réinitialisation du mot de passe », ce qui pourrait compliquer les choses (bien que ce ne soit probablement pas un obstacle complet).
C’est bien ça. Avec masquer l'adresse e-mail déjà utilisée activé, vous devez entrer l’e-mail du compte lui-même pour la réinitialisation du mot de passe, et vous ne pouvez pas simplement utiliser un nom d’utilisateur.
Je suggère de renommer le SiteSettinghide_email_address_taken en prevent_password_recovery_by_username, puis de refactoriser le comportement non conforme hors de l’application pour tous les utilisateurs. Cela préserverait la fonctionnalité de réinitialisation du mot de passe sans modification pour toutes les installations, tout en abordant la vulnérabilité d’énumération d’e-mails. Je suis un développeur RoR + javascript expérimenté et je serais heureux d’implémenter cette pull request ; j’ai jeté un coup d’œil rapide au code et je vois que ce ne serait pas une PR très étendue.
Si le refactoring de cette « fonctionnalité » pour la faire disparaître n’est vraiment pas envisageable, je pense toujours qu’il est logique de découpler ces deux concepts liés en entrées SiteSetting distinctes.
)
