Protecting against gmail dot trick in Discourse

Contribuir Funcionalidade
61

Não sei, @sam, isso parece mais uma necessidade de um plugin de CAPTCHA para criação de usuários? Não sinto que “proibir pontos e sinais de mais” trate a doença subjacente; isso apenas aborda os sintomas do problema? :thinking:

Historicamente, a tendência tem sido de spamistas 100% humanos ao longo do tempo. Quero dizer, eles preenchem perfis de usuário, fazem upload de imagens de perfil e tudo mais. Spammers automatizados (exceto o bamwar) não têm sido um grande problema no Discourse, pois somos muito difíceis de automatizar, já que somos uma aplicação completa em JavaScript. Note que a maioria dos seus comentários, @neounix, se enquadra na categoria descrita na minha frase anterior: é muito difícil nos scriptar porque somos tão complexos, comparados a um site de HTML 1.0 da era de 1999. Elevar a barra de dificuldade a esse ponto elimina a maior parte do problema, com base no que observamos com nossos clientes e aqui no meta.

De qualquer forma, TL;DR: não sou necessariamente contra uma configuração simples de “proibir certos caracteres em e-mails”, suponho, mas no fundo não acho que nada além de um CAPTCHA vá ajudar muito neste caso? Poderíamos fazer os dois?

5 curtidas
62

Mas alguns usuários (incluindo eu) usam o + para realmente classificar e-mails no nosso cliente de e-mail.

3 curtidas
63

Sem problemas, isso não estaria ativado por padrão; seria mais um modo de “bloqueio contra ataques” via configuração do site.

7 curtidas
64

@neounix Lenda. Obrigado pelas dicas, muito apreciadas — você me mandou em uma jornada de combate a spam. Coloquei o Cloudflare no modo “Estou sob ataque” temporariamente (o que parou os registros deles — eles estavam criando uma nova conta a cada 1-2 minutos) e verifiquei os logs do firewall do Cloudflare para alguns IPs que eles estavam usando, percebendo que estava desafiando/registrando cada visitante. Eles realmente estavam usando useragents idênticos.

Adicionei uma regra de firewall para desafiar usuários com esse useragent e desativei o modo “Estou sob ataque” no CF. Não acredito que muitos inocentes tenham sido desafiados por isso e isso parou completamente os registros de spam deles.

Em seguida, descobri o recurso de bloqueio por Número de Sistema Autônomo (ASN) que o Cloudflare possui e configurei regras de firewall adicionais para bloquear uma quantidade significativa deles, referenciando os logs de bloqueio por useragent. Existem contornes para isso, tenho certeza que você conhece, mas é um custo e esforço adicionais de recursos para eles.

:content:

@codinghorror Concordo com você de que os captchas seriam úteis. Diria que um bom objetivo principal de prevenção de spam seria aumentar os custos gerais de recursos para spammers.

Captchas contribuiriam para isso. US$ 2, mais ou menos, por mil resoluções de recaptcha (usando uma API de resolução de captcha, por exemplo, https://anti-captcha.com). Além de complexidades extras necessárias para os bots deles.

Observação lateral: O Anti-captcha tem um plugin de navegador para resolver automaticamente seus captchas, funciona bem e é uma conveniência divertida. :goodnews:

Endereços de e-mail geralmente são outro custo de recursos para criação de contas em massa. No entanto, não é o caso quando um único usuário pode criar virtualmente contas ilimitadas por endereço único do Gmail. O custo de 1000 contas do Gmail é bastante significativo, então eles frequentemente recorrem a outros provedores menos rigorosos ou domínios catchall. Ainda assim, isso custará recursos para eles e é mais fácil identificar como spam.

Acho que realmente é o caso de “quanto mais, melhor”. Nenhuma defesa única será forte o suficiente; apenas aumentar a quantidade de recursos e esforço necessários dos spammers em geral são passos na direção certa. O melhor cenário é que seja mais trabalhoso para spammers fazerem spam em fóruns Discourse do que para administradores bloquearem e removerem em massa qualquer coisa que passe.

@itsbhanusharma Gosto muito de poder usar + também, mas é por isso que não podemos ter coisas legais, haha. Seria bom ter a opção de ativar o bloqueio, se necessário para combater spammers.

2 curtidas
65

Depois de pensar sobre isso, estou inclinado a concordar com você nisso.. @sam, podemos priorizar essa configuração de bloqueio de e-mail para a próxima semana?

5 curtidas
66

O assunto já foi discutido bastante acima, exatamente neste tópico.
“Proibir” pontos e sinais de mais provavelmente causaria alguns problemas (pelo menos para alguns usuários). A ideia era armazenar uma versão “canônica” do e-mail (versão “limpa”) e impedir o registro de novos usuários com a mesma versão canônica para o Gmail (=na verdade, o MESMO e-mail, graças aos truques do Gmail).

Isso pode ser o que Sam está dizendo quando ele afirma:

Talvez seja isso que você também quis dizer, @codinghorror, e não realmente “proibir” . e +.
Mas concordo com você de que isso apenas “resolveria” o problema para o Gmail (não o uso de um “catchall” com um domínio, por exemplo).

Um CAPTCHA realmente resolveria algo quando você mesmo diz:

?

67

Parece que pulamos uma etapa.

Forçar o uso do e-mail canônico é problemático, mas bloquear mais de uma conta por e-mail canônico por padrão é bastante razoável.

A maioria de nós tem mais de um endereço de e-mail se precisarmos de uma conta de teste. Isso não causará problemas significativos nesse caso. Se for uma configuração padrão, não precisaremos educar as pessoas para ativá-la após a ocorrência de abusos.

1 curtida
68

Os sinais de mais (+) em e-mails podem, em minha opinião, ser tratados de forma mais ou menos uniforme em todos os domínios de e-mail, sem muitos problemas.

Para e-mails como sp.a.mmer.king@gmail.com ou s.pa.mmerking@gmail.com, no caso do Gmail, eles representam o mesmo endereço de e-mail. No entanto, para alguns outros provedores, isso pode não ser verdade, e ambos os e-mails podem ser considerados de usuários distintos.

–

Acho que uma boa implementação para o longo prazo seria algo semelhante ao recurso de lista negra de domínios de e-mail.

Adicione um domínio personalizado que você deseja proibir para evitar truques de registro duplicado. Em seguida, permita ativar ou desativar o bloqueio desses dois tipos de registros duplicados de forma independente. Ou seja, ofereça opções separadas para proibir duplicatas por meio do truque do sinal de mais (+) e do truque do ponto (.).

Armazene o e-mail registrado exatamente como foi fornecido (em termos de login do usuário e do endereço para o qual os e-mails são enviados), mas bloqueie registros adicionais que sejam identificados como o mesmo e-mail.

Outra coisa que tornaria a solução um pouco mais eficaz seria permitir que vários domínios fossem agrupados em um único registro de domínio personalizado, de modo que sejam tratados como o mesmo domínio. Por exemplo, gmail.com e googlemail.com. Assim, alguém poderia ser impedido de se registrar duas vezes usando, por exemplo, example@gmail.com e example@googlemail.com. Existem outros provedores que possuem múltiplos domínios intercambiáveis; enviei alguns exemplos para o Sam. Isso poderia adicionar um pouco mais de proteção, mas, de modo geral, o principal problema explorável são os registros que utilizam os truques do sinal de mais (+) e do ponto (.).

–

Alternativamente, uma implementação potencialmente mais simples seria semelhante à descrita acima, mas as duas opções para cada domínio de e-mail personalizado seriam bloquear todos os registros que contenham sinais de mais (+) e/ou pontos. Se um usuário tentar se registrar nesse domínio usando um sinal de mais ou um ponto, exiba uma mensagem de erro instruindo-o a remover os pontos e/ou os sinais de mais do e-mail (possivelmente fazendo isso automaticamente para ele) e tentar novamente. Não é perfeito, mas ainda seria muito eficaz.

69

Correto, é por isso que reduziríamos ao e-mail canônico para garantir que sejam únicos. Isso já foi abordado acima. No entanto, não podemos armazenar o e-mail canônico como o endereço de e-mail deles, pois não é o que eles forneceram.

Listas negras de domínios já existem, mas não podemos assumir que, apenas porque um usuário também pode ser alcançado por um endereço googlemail ou gmail, devemos rejeitar um ou outro. Daí a referência a um “mestre” canônico.

Há sites hoje em que os usuários estão usando legítima e adequadamente o endereçamento com sinal de mais e pontos. O objetivo não é dificultar práticas legítimas, apenas limitar os efeitos colaterais desproporcionais, como dois usuários para um único endereço canônico.

70

Se for necessário fornecer o e-mail com os pontos e sinais de mais removidos durante o processo de registro, no lado do cliente e com consentimento (semelhante à validação de formulário), armazená-lo como o e-mail da conta deles seria aceitável.

Não é ideal ou perfeito, mas potencialmente mais simples e uma troca válida em alguns casos onde a escolha é entre incomodar alguns usuários ou incomodar todo o fórum com spam.

Existem contas do Gmail cujo e-mail canônico principal inclui pontos. Seriam os usuários mais afetados e confusos pela remoção forçada desses pontos durante o registro.

Não acho que essa seria a melhor implementação, e definitivamente não seria uma opção padrão amigável.

Certo, o que quis dizer foi ter um menu de opções semelhante à lista negra de domínios de e-mail já existente, para inserir quais domínios de e-mail devem ser afetados e os parâmetros do que deve ou não ser usado para decidir se um endereço de e-mail é único/canônico, conforme discutido neste tópico. Potencialmente, também quais domínios devem ser considerados o mesmo host, por exemplo, gmail/googlemail.

Em relação ao gmail e googlemail, acho que estamos de acordo. O mesmo vale para os pontos e sinais de mais.

Essencialmente, permitir que o primeiro registro seja concluído, mas impedir que o usuário crie múltiplas contas usando o mesmo e-mail. Ou, pelo menos, minimizar isso dentro do razoável.

john@googlemail.com registra primeiro → aceito
john@gmail.com registra depois → rejeitado

matthew+{stringaleatória}@gmail.com registra primeiro → aceito
matthew@gmail.com registra depois → rejeitado
matthew@googlemail.com registra depois → rejeitado
m.att.he.w@gmail.com registra depois → rejeitado
matthew+{stringaleatória}@gmail.com registra depois → rejeitado
m.a.tt.ew+{stringaleatória}@googlemail.com registra depois → rejeitado

A questão do googlemail versus gmail (e outros provedores que têm vários domínios alternativos) é muito menos significativa do que os problemas relacionados a pontos e sinais de mais. No entanto, seria bom lidar com esses casos também.

71

Essa é uma mudança realmente hostil ao usuário e totalmente desnecessária. A razão pela qual esses recursos existem é identificar a origem do e-mail. Se eu me registrar usando o endereço stephen+meta@gmail.com, posso configurar uma regra que permite que qualquer e-mail enviado para esse endereço seja rotulado. Se o Meta for comprometido e meu endereço de e-mail começar a receber spam nesse alias, saberei onde ocorreu a violação. Limitar a forma como uso o e-mail não é a solução; reduzir meu endereço de e-mail a uma versão canônica para comparação alcança o mesmo resultado sem causar qualquer inconveniente ao usuário.

Certo, e isso está ligado ao conceito de um endereço canônico. Se o recurso fosse implementado como originalmente discutido, nos beneficiaríamos muito da capacidade de associar domínios. Cada permutação de pontos e sinais de mais e variação de domínio seria comparada a um único “e-mail verdadeiro” para aquela caixa de correio, sem causar nenhuma fricção.

Desde que não causemos qualquer problema aos usuários, não há motivo para que esse recurso não possa ser ativado por padrão.

72

Concordo, solução imperfeita = imperfeita. Eu disse isso apenas como uma alternativa potencialmente mais simples de implementar. É a última parte do meu post, apresentada como uma alternativa às sugestões principais que eu estava fazendo, as quais concordam com grande parte das discussões neste tópico, além de permitir ‘+’ e pontos, apenas não contas duplicadas.

Dito isso, usuários legítimos usando ‘+’ em e-mails em fóruns/sites não técnicos é geralmente um caso de borda, pelo que tenho visto.

Soa realmente fantástico. :content:

Meu post focava principalmente em como os endereços canônicos são calculados para diferentes domínios de e-mail. Portanto, não se limita ao uso apenas com gmail/googlemail. Eu estava essencialmente tentando dizer que poderia ser uma boa implementação a longo prazo ter opções para os usuários sobre como os endereços canônicos são calculados por domínio.

Alguns outros provedores permitem ‘+’ mas não permutações de ponto, por exemplo. O que significa que as permutações de ponto são e-mails únicos.

Uma implementação apenas para gmail/googlemail seria ótima, e não vejo nenhum motivo para que não possa ser ativada por padrão também.

73

Você poderia fornecer um exemplo? Pergunto isso porque a maioria dos usuários do Gmail não conhece o truque dos pontos. Eles se cadastraram com um endereço que inclui pontos, fornecem essa versão do e-mail a todos e ficariam muito confusos se lhes dissessem que “seu e-mail” é inválido.

Raramente encontro pessoas que percebam que seu alias, sem os pontos, ainda chegará até elas.

1 curtida
74

Claro, vou te enviar por mensagem privada um exemplo que enviei ao Sam. É que não tenho certeza se é uma boa ideia postar isso publicamente em um tópico com esse título, já que, felizmente, muitos spammers ainda não sabem disso.

Sim, concordo, essa seria a principal confusão para usuários comuns com essa solução imperfeita.

75

Não há como adotar uma abordagem tão complicada. Não vamos “normalizar” e-mails.

Ou você está no modo de bloqueio de e-mail, que impede completamente certos caracteres problemáticos em um endereço de e-mail (por domínio de e-mail codificado, talvez), ou não está.

É isso. Alternador booleano. Modo de bloqueio de e-mail, Sim/Não?

3 curtidas
76

Referência:

Isso agora está concluído.

Use a configuração do site enforce_canonical_emails (padrão: false) para ativar essa proteção.

Uma vez ativada, não permitiremos registros duplicados para pessoas que usam o truque do . em googlemail.com e gmail.com, bem como o truque do + globalmente.

A correção é muito segura e não tem impacto algum fora da caixa quando está desativada.

Um efeito colateral da implementação é que mais uma conta duplicada passará por uma vez que você ativar a configuração, pois não armazenamos e-mails na forma canônica na tabela de e-mails do usuário, a menos que você ative a configuração. Isso é perfeitamente aceitável, na minha opinião, pois, em geral, não consigo encontrar casos desse abuso exato em vários sites que hospedamos.

8 curtidas
Suggestion: Wildcard Block Email Address
Suggestion: Wildcard Block Email Address
77

Armazenar a forma canônica de forma alguma é problemático. Que formato eles assumem?

78

A especificação está aqui:

Se a configuração do site não estiver habilitada, nada acontece… zero, nada de nada.

5 curtidas
80

Obrigado pelas palavras gentis @markersocial

Desculpe não ter respondido antes, estive ocupado com outras tarefas… apenas me recuperando no meta:

Detectar spam, registros falsos, ataques DDOS, intrusões e consciência situacional do ciberespaço em geral, além de todas as outras classes semelhantes de problemas de cibersegurança orientados à detecção e fusão de dados de múltiplos sensores, é um dos meus tópicos favoritos, como você parece saber :slight_smile:

Tendo estado na linha de frente e lutado muitas batalhas cibernéticas “mão na massa” em tempo real, deixe-me dar a você mais duas dicas quando estiver sob ataque como este:

(1) A detecção é frequentemente mais uma arte do que uma ciência pura. A razão é que quanto mais os atacantes souberem sobre seus algoritmos e técnicas de detecção e mitigação, mais eles vão mutar e se adaptar às suas defesas.

(2) Além disso, nunca esqueça o “Ciclo OODA”. Observar-Orientar-Decidir-Agir. Aquele(s) na batalha cibernética que conseguirem entrar dentro do ciclo OODA do(s) oponente(s), geralmente será o vencedor.

Estou feliz em ler que você está aproveitando a defesa cibernética e olhando para o quadro maior. Parece que você tem tudo sob controle (pelo que li rapidamente em resumo nesta discussão) e que a excelente equipe do meta também comprometeu uma mudança útil para você.

Se você cair sob ataque e precisar de ajuda, não hesite em entrar em contato comigo. Estou há muito tempo aposentado do mundo de buscar lucros e encher meus cofres (graças a Deus!), então nunca há taxa para consultar comigo. Ajudar outros que têm problemas técnicos interessantes, especialmente na área de cibersegurança e guerra cibernética, é uma prioridade maior para mim do que acumular mais riqueza.

Estou aqui para você se precisar de alguém para discutir ideias e, pelo que li de suas respostas recentes, parece que você tem as coisas sob controle.

Ótimo trabalho!

5 curtidas
81

@codinghorror Minha opinião aqui é que essa mudança é inútil e eu deveria simplesmente reverter minha alteração.

Nenhum dos nossos sites hospedados está solicitando isso ou modos de bloqueio de e-mail extremos. Nada disso é um problema na prática, pois nós removemos nossas contas inativas de qualquer forma e escaneamos perfis contra spam.

Spammers podem simplesmente rodar um servidor SMTP, o que é mais fácil do que automatizar o Gmail, e eles teriam acesso a infinitos e-mails dessa forma.

Além disso, o endereçamento com pontos é amplamente utilizado de maneiras legítimas.

O problema mais comum relacionado a pontos no Gmail não é spam, mas sim erros de digitação em e-mails.

Acho que a única mudança que apoio no núcleo é expandir o bloqueio de e-mails para incluir e-mails canônicos; pelo menos isso é uma melhoria na funcionalidade de bloqueio de e-mails e resolve o problema do OP.

Por exemplo, se você bloquear Jane@gmail.com, também bloqueia j.ane+1@gmail.com.

Qualquer outra mudança pode ser implementada em plugins.

Isso parece ok?

7 curtidas