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!
Questa funzionalità sta funzionando molto bene, @sam
Penso che la precedente implementazione che hai creato possa essere ancora molto utile come ulteriore misura anti-spam: ha funzionato in modo incredibile per il breve periodo in cui era disponibile e attiva (disattivata di default).
In caso contrario, gli spammer possono ancora creare account in blocco utilizzando un unico indirizzo Gmail prima che un moderatore o un amministratore se ne accorga. Ad esempio, creando gli account ma senza pubblicare nulla immediatamente.
Gli amministratori/moderatori dovranno cercare e aprire manualmente ogni singolo account per bannarlo o eliminarlo. Questo può essere piuttosto laborioso, soprattutto quando uno spammer può creare centinaia o migliaia di account con un unico Gmail prima di essere bannato. Inoltre, la ricerca delle email è difficile, ad esempio tra j.ohan.2.1@gmail e jo.ha.n21@gmail.
Se non vengono individuati manualmente, gli spammer mantengono un vasto pool di account con cui giocare a “colpisci la talpa”, spendendo solo un account Gmail per ottenerli tutti.
@sam Solo per un aggiornamento dopo ulteriori test sul campo, credo che l’implementazione precedente che è stata annullata sia decisamente molto più efficace contro gli spammer motivati. Sto ancora ricevendo un numero significativo di registrazioni che utilizzano questi trucchi con Gmail permutati.
Sono molto grato che sia stata implementata la protezione attuale, che è molto efficace. Tuttavia, penso che sia un punto debole permettere la creazione di account illimitati utilizzando lo stesso indirizzo email finché non vengono specificamente individuati e bannati manualmente. Questo rappresenta un ulteriore carico per i moderatori (che non possono vedere gli indirizzi email degli account per impostazione predefinita, a meno che non sia abilitato, credo), specialmente in assenza di strumenti per la rimozione degli account in blocco (ad esempio, selezionare diversi account dall’elenco accounts/search con le caselle di controllo e bannarli/rimuoverli tutti). Ciò significa che un moderatore dovrà navigare manualmente verso ogni singolo account per rimuoverli/bannarli. Questo è particolarmente difficile quando si cercano account con indirizzi email permutati.
Visto che l’implementazione precedente era opzionale (disattivata per impostazione predefinita), è già stata sviluppata e ha funzionato come previsto, per poi essere rimossa. Sembra solo un peccato che non sia più disponibile per le comunità che vorrebbero utilizzarla per una protezione antispam aggiuntiva contro gli spammer motivati.
Per questo ho detto che certi caratteri devono essere completamente disabilitati negli indirizzi email (opzionalmente). Nello specifico, i caratteri che abilitano la sottogestione degli indirizzi, come il segno più, il punto, il trattino, ecc. Con un’espressione regolare è possibile bloccarli anche per singolo servizio, ad esempio: «non sono ammessi indirizzi email con il segno più che terminano con @gmail.com». cc @sam
L’implementazione precedente consentiva ancora l’uso di +addressing mantenendo comunque un solo indirizzo canonico per account (cosa che, a mio avviso, è probabilmente più sicura).
Quindi, ad esempio, potevi registrarti come sam+discourse-meta@gmail.com, il che è comodo per le regole interne di Gmail che hai impostato. Tuttavia, ciò avrebbe bloccato la creazione di nuovi account da sam@gmail.com o sam+1@gmail.com.
Non sono contrario all’aggiunta di una allowlist, ma ritengo che l’obbligo di utilizzare indirizzi canonici sia molto utile nel caso di Gmail e rappresenta una scelta predefinita ragionevole.
La sicurezza non è davvero l’obiettivo qui. Il sito in questione ha bisogno di una soluzione più estrema a causa dell’entità del problema che sta affrontando. Finché è opzionale (aggiungi la tua “regex di protezione email”), mi sembra perfettamente sicuro per i siti che ne hanno bisogno: possono attivare la Modalità Blocco Totale.
Tuttavia, ottenere la regex corretta è piuttosto fastidioso a causa di tutte le sequenze di escape necessarie. Mi preoccupa offrire opzioni del genere, perché le probabilità che le persone scrivano la regex correttamente e come previsto sono piuttosto basse. Devono ricordare di escapare i punti e i simboli più.
.*\+.*@gmail\.com
Potremmo, immagino, creare un modello semplificato non basato su regex che espanda semplicemente * e ?.
Se l’implementazione precedente venisse reintrodotta come opzione, credo che risolverebbe completamente il problema di Gmail. Almeno nel mio caso. A mio avviso è perfetta e aggiunge costi sufficienti agli spammer da rendere gestibile la lotta contro di loro. Farebbe davvero la differenza tra dover richiedere una moderazione intensiva a tempo pieno 24 ore su 24 e non doverlo fare.
Ho bloccato diversi domini che permettono comportamenti simili e faccio uso dell’elenco dei domini email consentiti. Il problema è che le persone possono creare molti account prima che uno di loro venga bannato/bloccato (il che attiva il blocco delle permutazioni di quell’indirizzo Gmail per nuovi account, ma gli account esistenti rimangono invariati). Questo rende il lavoro di moderazione molto oneroso e la pulizia di ciascun account successivo diventa tediosa.
Ad esempio, ho avuto un thread con circa 200 risposte, una per account, tutti creati con lo stesso indirizzo Gmail. Ci sono molti casi simili. Questi sono esempi in cui gli account sono facili da individuare, poiché cercarli tramite permutazioni dell’indirizzo Gmail originale è molto difficile come alternativa. Alcuni creano grandi quantità di account usando solo pochi indirizzi Gmail e non li utilizzano per pubblicare fino a mesi dopo.
Per quanto riguarda la soluzione basata su regex, bloccare il segno + sarebbe relativamente innocuo, mentre bloccare i punti (.) probabilmente impedirebbe l’uso di molti indirizzi email legittimi, ad esempio john.smith@gmail.com. Bloccare gli indirizzi con più di un punto causerebbe probabilmente danni collaterali minimi, anche se permetterebbe ancora diverse permutazioni di un indirizzo Gmail, ma molto meno rispetto a due o più punti.
A mio avviso, l’implementazione precedente è ideale e non irragionevole da implementare come protezione opzionale; i siti sociali più popolari non permettono la registrazione utilizzando diverse permutazioni di Gmail a causa dello sfruttamento massiccio da parte degli spammer.
@Sam, sono fermamente convinto che i siti dovrebbero poter implementare questo livello opzionale di blocco regex per le email, se ne hanno bisogno. Altrimenti andremmo contro uno dei principi fondamentali di Discourse, ovvero essere “sicuri per impostazione predefinita”.
Possiamo completare questo per la prossima release, ma resto comunque convinto della mia implementazione originale: la canonicalizzazione è la soluzione più amichevole per gli amministratori del sito; spunti una casella e, fatto, il problema è risolto. Con le espressioni regolari, devi invece imparare a usarle (quindi via 5 ore) e rischi di finire con una soluzione che lascia passare account spam, è ostile all’utente (niente punti, niente simboli +) o è un compromesso.
Detto questo, certo, possiamo inserire il supporto per le espressioni regolari nella prossima release.
Beh, è davvero semplice: basta dire “non sono consentiti indirizzi email con il simbolo + o il punto”. Ammettiamolo, è piuttosto restrittivo e ovviamente non vorremmo che fosse attivo di default. Ma è come la questione di Bamwar: ci saranno sempre abbastanza attori malintenzionati da costringerti ad avere il pulsante di lancio nucleare, anche se non hai intenzione di usarlo.
È come la guerra nucleare. Una volta che le bombe atomiche sono sul tavolo, le opzioni “user-friendly” non sono più possibili; devi solo sperare che nella maggior parte dei casi non ti capiti mai di dover arrivare a quel punto.
Scusa per il ritardo nella risposta!