Cacher « e-mail déjà pris » lors de l'inscription par défaut

Contexte

Dans les paramètres par défaut actuels, lors de l’inscription d’un compte avec une adresse e-mail déjà enregistrée, le formulaire d’inscription le signalera :

Nous modifions le paramètre par défaut pour ne pas divulguer cette information. Au lieu de cela, le formulaire d’inscription ressemblera à ceci, que l’adresse e-mail soit déjà enregistrée ou non :

Cela affecte également les réinitialisations de mot de passe de manière similaire. Avec le paramètre désactivé, le formulaire fournit un retour immédiat indiquant que l’adresse e-mail est dans le système :

Avec le paramètre activé, il ne divulgue pas cette information :

Pourquoi changeons-nous cela ?

Un acteur malveillant peut utiliser ce retour pour effectuer un dénombrement de comptes , leur permettant de savoir si certains utilisateurs existent sur ce forum, ce qui peut ensuite leur permettre de cibler ces utilisateurs avec du phishing.

Cela n’affectera-t-il pas négativement les utilisateurs légitimes ?

Le cas ici est si un utilisateur oublie qu’il a déjà un compte, et qu’il essaie de s’inscrire ou de réinitialiser son mot de passe en utilisant la même adresse e-mail, ce qui devrait être une occurrence relativement rare. Mais même dans ce cas, il recevra un e-mail lui indiquant qu’il a déjà un compte.

Le changement n’affecte finalement pas la capacité des utilisateurs légitimes à s’inscrire ou à accéder à leurs comptes.

Mais je préfère l’ancien défaut

Si vous avez modifié ce paramètre à un moment donné, le nouveau défaut ne remplacera pas le paramètre personnalisé. Si vous souhaitez revenir à l’ancien défaut, vous pouvez définir le paramètre hide_email_address_taken sur false.

Remarque : nous envisageons de masquer ce paramètre de site de la page des paramètres administrateur à l’avenir.

10 « J'aime »

Que se passe-t-il dans le cas où l’utilisateur se souvient mal de l’adresse e-mail qu’il a utilisée pour s’inscrire ?

Par exemple, supposons que l’utilisateur pense s’être inscrit sous example@gmail.com mais qu’il s’est en fait inscrit sous example@yahoo.com. Il tentera une réinitialisation de mot de passe en fournissant l’adresse e-mail example@gmail.com, mais il n’y a pas de compte avec cette adresse e-mail.

Si un compte correspond à ted@discourse.org, vous devriez recevoir un e-mail avec des instructions sur la façon de réinitialiser votre mot de passe sous peu.

Si l’utilisateur ne reçoit tout simplement pas d’e-mail dans ce cas, il ne saura jamais qu’il a fourni la mauvaise adresse e-mail, et ne saura pas quand/s’il doit réessayer avec une adresse e-mail différente.

Au lieu de cela, le message devrait simplement dire : « Vous devriez recevoir un e-mail avec des instructions sur la façon de réinitialiser votre mot de passe sous peu », et l’utilisateur devrait recevoir un e-mail expliquant : « Quelqu’un a demandé une réinitialisation de mot de passe pour example@gmail.com, mais il n’y a pas de compte avec cette adresse e-mail. »

Cela ne permettra à personne d’effectuer un dénombrement de comptes, mais cela permettrait à l’utilisateur de savoir qu’il a soumis la mauvaise adresse e-mail, et d’en essayer une autre.

5 « J'aime »

Le problème avec cette approche est qu’elle permet à des acteurs malveillants d’envoyer des e-mails à des adresses qui n’ont jamais interagi avec votre instance, ou qui n’existent pas.

Cela pourrait entraîner un nombre beaucoup plus élevé d’e-mails envoyés, potentiellement à un coût monétaire élevé. Cela pourrait également entraîner une forte augmentation du nombre d’utilisateurs signalant du spam et un taux de rebond plus élevé, ce qui pourrait amener des opérateurs comme Gmail à blacklister vos e-mails.

5 « J'aime »

Les attaquants pouvaient déjà le faire simplement en enregistrant de nouveaux comptes. Si l’attaquant connaît 100 000 adresses e-mail, il peut enregistrer 100 000 comptes, et Discourse enverra à chacun d’eux un e-mail d’activation, que chaque utilisateur pourrait signaler comme spam.

L’envoi d’e-mails « impossible de réinitialiser le mot de passe, votre compte n’existe pas » à des adresses e-mail de comptes qui n’existent pas ne rend pas cette attaque plus facile ou plus difficile.

Cette attaque n’est pas un problème pour la plupart des sites, mais si cela vous inquiète, vous devriez utiliser le plugin Discourse hCaptcha, qui augmente le coût pour l’attaquant. (Meta ne l’utilise pas ; la plupart des forums hébergés par Discourse ne l’utilisent pas.)

Je pense que si Discourse accepte ma suggestion de commencer à envoyer des e-mails « impossible de réinitialiser le mot de passe, votre compte n’existe pas » aux adresses e-mail de comptes qui n’existent pas, il serait logique que le plugin hCaptcha fonctionne également sur le formulaire de réinitialisation de mot de passe ainsi que sur le formulaire d’inscription. (Je n’aurais toujours pas besoin/n’utiliserais pas hCaptcha moi-même.)

3 « J'aime »

Oui, c’est valable. Je n’avais pensé qu’au cas en soi, sans considérer d’autres domaines où c’est déjà possible et, comme il se trouve, complètement irréalisable à empêcher.

Mais ne le savent-ils pas ?

  1. J’ai oublié mon mot de passe et je veux accéder à ce site. Je saisis ce que je pense être la bonne adresse e-mail.
  2. Je ne reçois pas de lien de réinitialisation de mot de passe.

Je connais donc automatiquement l’une des deux options : soit j’ai entré la mauvaise adresse e-mail, soit le site ne fonctionne pas correctement.

Mes options sont maintenant : essayer une autre adresse e-mail, ou essayer de contacter quelqu’un qui gère le site.

Maintenant, avec votre suggestion, je reçois un e-mail m’indiquant que le compte n’existe pas. Mes options sont essayer une autre adresse e-mail, ou contacter quelqu’un qui gère le site. C’est le même point final avec 0 étape supplémentaire.

1 « J'aime »

Sauf que… la plupart des utilisateurs ordinaires ne pensent pas de cette façon, ou pas du tout.

1 « J'aime »