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!
Essa funcionalidade tem funcionado muito bem, @sam
Acho que a implementação anterior que você criou ainda pode ser bastante útil como uma funcionalidade adicional de anti-spam. Ela funcionou incrivelmente bem durante o curto período em que esteve disponível e ativa (desativada por padrão).
Caso contrário, spammers ainda podem criar contas em massa usando um único endereço do Gmail antes que um moderador ou administrador perceba. Por exemplo, criar as contas mas não publicar nada imediatamente.
Administradores e moderadores precisarão encontrar e abrir manualmente cada conta individual para banir ou excluí-las. Isso pode ser bastante tedioso, especialmente quando um spammer pode criar centenas ou milhares de contas com um único Gmail antes de ser banido. Além disso, a busca por esses e-mails é difícil, por exemplo: j.ohan.2.1@gmail e jo.ha.n21@gmail.
Se eles não forem caçados manualmente, os spammers manterão um grande pool de contas para jogar no jogo de “quebra-cabeça”, enquanto precisarão gastar apenas uma conta do Gmail para obtê-las.
@sam Apenas para dar um retorno após mais testes em campo, acredito que a implementação anterior que foi revertida é definitivamente muito mais eficaz contra spammers motivados. Ainda estou recebendo uma quantidade significativa de registros usando esses truques de permutação do Gmail.
Agradeço muito que a proteção atual tenha sido implementada, pois é muito eficaz. No entanto, acho que é uma falha permitir a criação de contas ilimitadas usando o mesmo e-mail até que sejam especificamente notadas e banidas manualmente. Isso representa uma sobrecarga para os moderadores (que não podem ver os e-mails das contas por padrão, a menos que essa opção seja ativada, creio eu), especialmente na ausência de ferramentas de remoção em massa de contas (por exemplo, selecionar várias contas na lista de pesquisa de contas com caixas de seleção e bani-las/removê-las todas). Isso significa que um moderador precisará navegar manualmente até cada conta individual para removê-la/bani-la. Isso é especialmente difícil ao procurar contas com e-mails permutados.
Considerando que a implementação anterior era opcional (desativada por padrão), já havia sido desenvolvida e funcionava conforme o esperado, e depois foi removida, parece realmente uma pena que ela não esteja mais disponível para comunidades que gostariam de usá-la para proteção adicional contra spammers motivados.
É por isso que disse que certos caracteres devem ser completamente proibidos em e-mails (opcionalmente). Especificamente os caracteres que permitem sub-endereçamento, conforme descrito em Email address - Wikipedia, como o sinal de mais, ponto, hífen, etc. Com uma expressão regular, você também pode bloquear isso por serviço, por exemplo: “nenhum e-mail com um sinal de mais terminando em @gmail.com é permitido”. cc @sam
A implementação anterior ainda permitia o uso de +addressing, mantendo apenas um endereço canônico por conta (o que, na minha opinião, é provavelmente mais seguro).
Assim, você poderia se registrar como sam+discourse-meta@gmail.com, o que é útil para regras internas do Gmail que você tenha configurado. No entanto, isso impediria a criação de novas contas a partir de sam@gmail.com ou sam+1@gmail.com.
Não sou contra adicionar uma lista de permissões, mas acho que a imposição de endereços canônicos é bastante útil no caso do Gmail e não é uma configuração padrão ruim.
Segurança não é realmente o objetivo aqui. O site em questão precisa de uma solução mais extrema devido à magnitude do problema que enfrenta. Desde que seja opcional (adicione sua própria “expressão regular de proteção de e-mail”), parece perfeitamente seguro para mim. Para os sites que precisam, eles podem optar pelo Modo de Bloqueio Total.
No entanto, acertar a regex é meio chato, dada toda a necessidade de escape. Preocupa-me oferecer opções assim, pois a probabilidade de as pessoas acertarem a regex conforme o pretendido é bastante baixa. Elas precisam lembrar de escapar pontos e sinais de mais.
.*\+.*@gmail\.com
Poderíamos, talvez, fazer um padrão simplificado sem regex que apenas expanda * e ?.
Se a implementação anterior fosse reativada como uma opção, acredito que isso resolveria completamente o problema do Gmail. Pelo menos no meu caso. Na minha opinião, é perfeito e adiciona custos suficientes de recursos para os spammers, tornando o combate gerenciável. Seria realmente a diferença entre exigir moderação em tempo integral, 24 horas por dia, de alta intensidade ou não.
Bloqueei vários domínios que permitem endereços semelhantes e fazem uso da lista de domínios de e-mail permitidos. O problema é que as pessoas podem criar várias contas antes de ter uma delas banida/bloqueada (o que ativa o bloqueio de permutações desse endereço do Gmail para novas contas, mas as contas existentes permanecem intactas). Isso se torna um grande ônus para a moderação e trabalhoso para limpar cada conta individual posteriormente.
Por exemplo, tive um tópico com cerca de 200 respostas, usando 1 postagem por conta, todas feitas com o mesmo endereço do Gmail. Muitos casos semelhantes. Esses são exemplos onde as contas são fáceis de encontrar, já que buscá-las por meio de permutações do e-mail original do Gmail é realmente difícil como alternativa. Alguns criam grandes quantidades de contas usando apenas alguns endereços do Gmail e não postam nelas até meses depois.
Para o bloqueio por regex como solução, bloquear sinais de + seria relativamente inofensivo, enquanto pontos (.) provavelmente bloqueariam uma quantidade significativa de e-mails legítimos, ou seja, john.smith@gmail.com. Bloquear endereços com mais de um ponto provavelmente causaria danos colaterais mínimos, embora ainda permitiria várias permutações de um endereço do Gmail, mas muito menos do que com 2 ou mais pontos.
Na minha opinião, a implementação anterior é ideal e não é irracional implementá-la como uma proteção opcional; a maioria dos sites sociais mais populares não permite o cadastro usando várias permutações do Gmail devido à forte exploração por spammers.
@sam, sinto-me bastante firme na ideia de que os sites devem ter permissão para implementar esse nível opcional de bloqueio por regex de e-mail, se precisarem. Caso contrário, estaremos indo contra um dos princípios fundamentais do Discourse, que é ser “seguro por padrão”.
Podemos fazer isso para a próxima versão, mas ainda mantenho minha implementação original: a normalização é a solução mais amigável para os administradores de sites — você marca uma caixa e, pronto, o problema está resolvido. Com expressões regulares, você precisa aprender regex (então, adeus a 5 horas) e acaba com uma correção que permite a passagem de contas de spam ou é hostil ao usuário (sem pontos, sem sinais de mais) ou é um compromisso.
Dito isso, claro, podemos incluir o suporte a regex na próxima versão.
Nah, é bem fácil: basta “não permitir e-mails com sinal de mais ou ponto” — o que, admitidamente, é bastante restritivo e, obviamente, não deveríamos ter ativado por padrão. Mas é como a questão do Bamwar: sempre haverá agentes mal-intencionados suficientes para que você precise ter o botão de lançamento nuclear, mesmo que não queira usá-lo.
É como uma guerra nuclear. Uma vez que as armas nucleares estão em jogo, as opções “amigáveis ao usuário” deixam de ser viáveis; você só pode torcer para que, na maioria das vezes, nunca precise chegar a esse ponto.
Desculpe pela resposta tardia!