Seria bom se houvesse uma maneira de adicionar endereços de e-mail bloqueados com curingas. Por exemplo, quando um spammer usa o truque do ponto no Gmail.
Todos são o mesmo endereço de e-mail; spammers podem usar um único endereço do Gmail para criar contas ilimitadas facilmente.
Bloquear um endereço com curingas como abaixo, acredito, seria uma boa solução: e*x*a*m*p*l*e*@gmail.com
Não acho necessariamente que todas as inscrições usando essas variações de endereço do Gmail devam ser bloqueadas, apenas que seria útil que, se um endereço do Gmail for bloqueado, todas as variações também o sejam, ou que possamos adicionar manualmente um Gmail com curinga à lista negra de e-mails.
Você está enfrentando um problema específico ou isso é apenas uma teoria? Se for um problema específico, você pode compartilhar os e-mails dos spammers?
Sim, é um problema real que estou enfrentando. Tenho spammers criando regularmente dezenas de milhares de contas a partir de um único endereço do Gmail usando o método do ponto e uma quantidade suficiente de IPs.
Até onde vi, apenas o truque do ponto está sendo usado, mas não tenho 100% de certeza se o método com o sinal de mais (+) também funciona. Na última verificação, era possível se registrar usando endereços de e-mail com o caractere +, então esse truque também deveria funcionar.
Pode gerar 16.777.216 endereços de e-mail únicos usando apenas o método do ponto e praticamente ilimitados usando o método com o sinal de mais (+). Isso torna tudo super eficiente para spammers. A blacklist de domínio não é viável, já que se trata do Gmail.
Você pode ver um gerador aqui (fica lento acima de 8 mil combinações): Redirecting...
Se isso fosse realmente implementado com uma abordagem semelhante a curingas (em vez de ser tratado automaticamente pelo Discourse), você provavelmente gostaria de ser muito mais específico do que e*x*a*m*p*l*e*@gmail.com. Fazer isso dessa forma poderia resultar no bloqueio de pessoas inocentes, especialmente se o endereço de e-mail do spammer for relativamente curto. Procurar especificamente por . e + provavelmente seria muito mais seguro.
Não entendo sua matemática. Você só pode adicionar um único ponto entre os caracteres, então cada endereço de N caracteres serve apenas para 2*n endereços. Você provavelmente poderia ter um plugin que salvasse ou comparasse com o endereço sem pontos e desabilitasse os endereços com +.
@pfaffman - Eu estava apenas seguindo os números fornecidos por Redirecting..., onde para cada caractere adicional acima de 2, a quantidade de endereços é duplicada (embore pare de crescer em cerca de 8 mil).
Acho que 2*n, se entendi corretamente o que você quis dizer (como se um endereço de 26 caracteres tivesse 52 combinações?), seria muito baixo. Afinal, é possível adicionar vários pontos ao longo do endereço.
Exemplo: 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
De qualquer forma, seja qual for o número exato, é uma quantidade enorme. Sim, a solução que você sugeriu faz sentido!
É. Eu não estava fazendo a conta direito. Eu estava permitindo apenas um ponto. Eu já sabia dessa matemática, mas não hoje de manhã.
Mas um plugin que salvasse uma tentativa e, além disso, oferecesse a versão gratuita do endereço como um endereço adicional faria o que você quer e não seria tão difícil.
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!