Are all the same email address, spammers can use one gmail address to make unlimited accounts easily.
Blocking an address with wildcards like below I believe would be a good solution: e*x*a*m*p*l*e*@gmail.com
I don’t necessarily think that all registrations using these gmail address variations should be blocked, just that it would be useful that if a gmail address is blocked, all variations are blocked too or that we can manually add a wildcard gmail to the email blacklist.
Yes it’s an actual problem I’m experiencing, I have spammers regularly making tens of thousands of accounts per single gmail account with the dot method and a sufficient pool of IPs.
I’m only seeing the dot trick being used, not 100% sure about if the + method works also. Last I checked it was possible to register using email addresses with + characters, so that trick should work too.
Can make 16,777,216 unique email addresses using the dot method only and essentially unlimited using the + method. Makes it super efficient for spammers. Domain blacklist isn’t viable seeing it’s gmail.
If this was actually implemented with a wildcard-like approach (instead of being handled automatically by Discourse), you’d probably want to be much more specific than e*x*a*m*p*l*e*@gmail.com. Doing it that way could result in blocking innocent people, especially if the spammer’s email address is relatively short. Looking specifically for . and + would probably be much safer.
I don’t understand your math. You can add only a single dot between characters, so each N-character address is good for only 2*n addresses. You could probably have a plugin that saved or compared against the dot-removed address and disallowed +addresses.
@pfaffman - I was just going off the figures given from Gmail Dot Trick Generator which is for every additional character above 2 the amount of addresses is doubled (it freezes at about 8k though).
I think 2*n, if I understand what you mean by this (as in a 26 character address would have 52 combinations?) would be too low. As they can add multiple dots throughout the address.
E.g: constantinehamilton1337x@gmail.com con.stantinehamilton1337.x@gmail.com co.nst.antineh.amilton1.3.37x@gmail.com constantineh.a.m.ilto.n13.37x@gmail.com c.o.nsta.ntinehamil.ton1337x@gmail.com
Anyhow, whatever the exact figure is, it’s a lot. Yeah, your suggested solution would make sense!
Ich denke, dass die vorherige Implementierung, die du erstellt hast, immer noch als zusätzliche Anti-Spam-Funktion sehr nützlich sein könnte. Sie hat in der kurzen Zeit, in der sie verfügbar und aktiviert war (standardmäßig deaktiviert), unglaublich gut funktioniert.
Andernfalls können Spammer weiterhin Massenkonten mit einer Gmail-Adresse erstellen, bevor ein Moderator oder Administrator dies bemerkt. Zum Beispiel das Erstellen der Konten, ohne sofort etwas zu veröffentlichen.
Administratoren/Moderatoren müssen jedes einzelne Konto manuell finden und öffnen, um es zu sperren/löschen. Das kann sehr mühsam sein, besonders wenn ein Spammer hunderte oder tausende Konten mit einer einzigen Gmail-Adresse erstellen kann, bevor er gesperrt wird. Auch ist die Suche nach den E-Mail-Adressen schwierig, z. B. j.ohan.2.1@gmail und jo.ha.n21@gmail.
Wenn sie nicht manuell aufgespürt werden, behalten die Spammer einen großen Pool an Konten, um das Spiel „Whack-a-Mole
@sam Nur ein kurzes Follow-up nach weiteren Feldtests: Ich bin überzeugt, dass die frühere Implementierung, die rückgängig gemacht wurde, gegen motivierte Spammer definitiv viel effektiver ist. Ich erhalte nach wie vor eine erhebliche Anzahl von Registrierungen, die auf diesen verschleierten Gmail-Tricks basieren.
Ich bin sehr dankbar, dass der aktuelle Schutz implementiert wurde, der sich als sehr wirksam erwiesen hat. Allerdings halte ich es für eine Schwachstelle, dass unbegrenzt viele Konten mit derselben E-Mail-Adresse erstellt werden können, bis sie speziell bemerkt und manuell gesperrt werden. Das bedeutet eine zusätzliche Belastung für Moderatoren (die standardmäßig keine E-Mail-Adressen der Konten einsehen können, es sei denn, diese Funktion ist aktiviert), insbesondere wenn keine Werkzeuge zur Massenentfernung von Konten vorhanden sind (z. B. mehrere Konten aus der Suchliste der Konten mit Kontrollkästchen auswählen und alle sperren/entfernen). Das bedeutet, dass ein Moderator manuell zu jedem einzelnen Konto navigieren muss, um es zu entfernen oder zu sperren. Das ist besonders schwierig, wenn man nach Konten mit verschleierten E-Mail-Adressen sucht.
Da die frühere Implementierung optional war (standardmäßig deaktiviert), bereits entwickelt wurde, wie vorgesehen funktionierte und dann entfernt wurde, scheint es einfach schade, dass sie für Communities, die sie für zusätzlichen Spam-Schutz gegen motivierte Spammer nutzen möchten, nicht mehr zur Verfügung steht.
Deshalb habe ich gesagt, dass bestimmte Zeichen in E-Mails (optional) vollständig verboten sein müssen. Konkret sind das die Zeichen, die eine Subadressierung ermöglichen, wie Pluszeichen, Punkt, Bindestrich usw. Mit einer Regex könnte man dies auch pro Dienst blockieren, z. B. „keine E-Mail mit einem Pluszeichen, die auf @gmail.com endet, ist erlaubt“. cc @sam
Die vorherige Implementierung erlaubte weiterhin +addressing, hielt die Anzahl der Kanonischen Adressen jedoch auf eine pro Konto (was ich wahrscheinlich sicherer finde).
Man konnte also als sam+discourse-meta@gmail.com registriert sein, was praktisch ist für interne Gmail-Regeln, die man hat. Anschließend wären jedoch neue Accounts von sam@gmail.com oder sam+1@gmail.com blockiert.
Ich bin nicht gegen das Hinzufügen einer Whitelist, aber ich finde, dass die Durchsetzung kanonischer Adressen im Gmail-Fall sehr praktisch ist und eine nicht schlechte Standardeinstellung darstellt.
Sicherheit ist hier nicht wirklich das Ziel. Die betreffende Website benötigt aufgrund des Ausmaßes des Problems, dem sie gegenübersteht, eine extremere Lösung. Solange es optional ist (fügen Sie Ihre eigene „E-Mail-Schutz-Regel
Allerdings ist es etwas mühsam, die richtige Regex zu erstellen, angesichts aller benötigten Escaping-Operationen. Ich bin besorgt, Optionen wie diese anzubieten, da die Wahrscheinlichkeit, dass Benutzer die Regex korrekt und wie beabsichtigt erstellen, recht gering ist. Sie müssen daran denken, sowohl Punkte als auch Pluszeichen zu escapen.
.*\+.*@gmail\.com
Wir könnten vielleicht ein nicht auf Regex basierendes, vereinfachtes Muster verwenden, das nur * und ? erweitert.
Wenn die vorherige Implementierung als Option wieder eingeführt würde, glaube ich, dass dies das Gmail-Problem vollständig lösen würde. Zumindest in meinem Fall. Das ist meiner Meinung nach perfekt und fügt Spammern genügend Ressourcenkosten hinzu, um die Bekämpfung überschaubar zu machen. Es wäre wirklich der Unterschied zwischen einer erforderlichen 24-Stunden-Vollzeit-Moderation mit hoher Intensität und keiner.
Ich habe mehrere Domains blockiert, die ähnliche Adressen zulassen, und nutze die Liste der erlaubten E-Mail-Domains. Das Problem ist, dass Nutzer viele Accounts erstellen können, bevor einer ihrer Accounts gebannt/blockiert wird (was das Blockieren von Permutationen dieser Gmail-Adresse für neue Accounts aktiviert, aber bestehende Accounts unberührt lässt). Das ist eine ziemliche Belastung für die Moderation und mühsam, um jeden einzelnen Account im Nachhinein zu bereinigen.
Zum Beispiel hatte ich einen Thread mit etwa 200 Antworten, wobei jeder Account nur einen Beitrag hatte, alle mit derselben Gmail-Adresse erstellt. Viele ähnliche Fälle. Dies sind Beispiele, bei denen die Accounts leicht zu finden sind, da das Suchen nach ihnen über Permutationen der ursprünglichen Gmail-Adresse als Alternative wirklich schwierig ist. Manche farmen eine große Anzahl von Accounts mit nur wenigen Gmail-Adressen und posten erst Monate später darauf.
Als Lösung für die Regex-Blockierung wäre das Blockieren von Pluszeichen (+) ziemlich harmlos. Punkte (.) würden wahrscheinlich eine erhebliche Anzahl legitimer E-Mails blockieren, z. B. john.smith@gmail.com. Das Blockieren von Adressen mit mehr als einem Punkt würde wahrscheinlich nur geringe Kollateralschäden verursachen, würde jedoch immer noch mehrere Permutationen einer Gmail-Adresse zulassen, aber deutlich weniger als bei 2 oder mehr Punkten.
Meiner Meinung nach ist die vorherige Implementierung ideal und als optionale Schutzmaßnahme nicht unvernünftig umzusetzen. Die beliebtesten Social-Media-Seiten erlauben keine Anmeldung mit mehreren Gmail-Permutationen, da dies stark von Spammern ausgenutzt wird.
@sam Ich bin der festen Überzeugung, dass Websites diese optionale Ebene der E-Mail-Regex-Einschränkung implementieren dürfen sollten, falls sie sie benötigen. Andernfalls verstoßen wir gegen eines der Kernprinzipien von Discourse, nämlich „standardmäßig sicher
Das können wir für das nächste Release erledigen. Ich bleibe jedoch bei meiner ursprünglichen Umsetzung: Canonicalisierung ist die benutzerfreundlichste Lösung für Site-Betreiber. Man setzt einfach ein Häkchen, und tada – das Problem ist gelöst. Bei Regex muss man erst Regex lernen (also sind 5 Stunden weg) und landet bei einer Lösung, die entweder Spam-Accounts durchlässt, benutzerunfreundlich ist (keine Punkte, keine Pluszeichen) oder ein Kompromiss darstellt.
Aber gut, klar, wir können Regex-Unterstützung für das nächste Release einplanen.
Entschuldigung für die späte Antwort!