Why wouldn’t he use it? I am not following. It fixes his attack problem.
In which case maybe the best place for it is marketplace ?
Better a third party breaks it than an “official” plugin?
It would never be an official plugin, just a 3 liner in my GitHub account if Jeff deems he wants it today.
It breaks email login for a bunch of legitimate accounts. Including my very email account on gmail.
Yes but I don’t think you use his site.
A certain number of civilian casualties are acceptable when you are at war. So what if 2% of users can’t sign up, when you’re being overwhelmed with thousands of fake-plus-addressed emails every day? It’s like cloudflare “I’m under attack” mode. Some legit people won’t get in. That’s the price you pay for the stricter security.
Your argument is that cloudflare “under attack” mode is not perfect therefore it should not exist 
At any rate I would need to see 2 more legit reports of this being a large scale problem before moving on it.
Forgive me if something obvious escaped me, but wouldn’t it be easier to add reCAPTCHA to the registration screen?
These are usually human spammers. There are quite a lot of them now compared to 2010. Captchas do nothing against a human adversary.
1 curtida
Ok…I thought this kind of “gmail dot and +” registration was mostly done by bots …
3 curtidas
A lot of genuine real humans use sharklasers et al (which use this) to sign up to our site because they don’t want their username attached to their real life person. It’ll depend per circumstance.
OP can set 15m read time as a trust req to posting and first 5 posts needing approving by staff with 0 edit rights and his issue I would wager disappears immediately.
1 curtida
One thing I would certainly like to confirm here is that we have reasonable rate limits for account registrations.
A single IP address should only be allowed to register N accounts per day. But we need some sort of bypass / site setting here for cases where NAT causes a big pile of users to share IP.
I prefer . be normalized for google, however +somthing remain as is. So perhaps if you’re going to do this, let admins choose what they want.
1 curtida
That’s already the case… the problem here is it is Mossad. They have lots and lots of IPs to use.
1 curtida
I am seeing rate limiters on:
- email login per hour
- update activation email
- resend activation email
- list second factors
- enable totp
- admin login
Not seeing any specific rate limit on account create short of the standard built in rate limiting per IP.
Curious if @markersocial can install data explorer and list registration ip address for the swamp of users that registered. I want to know for sure they are coming from 100 IP addresses vs just 1.
2 curtidas
I would like to agree, but Google has this problem. At the least University where I worked you couldn’t have a class sign up for Gmail because the university has all access from a single NAT.
I suspect that a NAT whitelist would solve most real world problems, as it’s probably predictable where legitimate users are coming from.
Default to a small (or configurable) number of IPs per day seems pretty safe to me.
@sam - Regarding the IPs, confirming that i do use registration + log in IP limiting and have a large banned IP list. I can assure you that it isn’t users creating significant amounts of accounts on the same IPs, I wish it was, then it would be possible to block. The only way to block them currently is blacklisting all gmail sign ups.
—
@codinghorror There is a non-illegal service that will give you access to xx,xxx,xxx unique IPs for $xxx per month. So it’s easy for anyone to get heaps of IPs, not just Mossad 
. There are lots of other legal services also offering large pools of IPs, then there are illegal rent-a-botnet services.
6 curtidas
I would definitely upgrade to latest, at a minimum scripts to do this bonanza are going to be much more annoying to write given my latest challenge/honeypot changes
Also please give us regular updates here, so we can learn more
Is this still going on right now?
5 curtidas
Ótimo, obrigado @sam e desculpe por ainda não ter dado um retorno sobre isso.
Sim, ainda parece bastante viável criar muitas contas usando esse truque (2.5.0.beta1).
Por exemplo, usando o truque de username+{stringaleatoria}@gmail.com, alguém criou 748 contas nas últimas 10 horas. Eles já têm milhares de contas usando esse único endereço do Gmail.
Praticamente a única maneira que tenho de removê-los da área de administração é acessando cada conta individualmente para suspender e/ou excluí-las. Não é muito viável, porque a pessoa pode simplesmente pressionar um botão e criar muitas outras contas. 
Eles parecem ter um suprimento praticamente ilimitado de IPs, então proibições ou limites por IP são praticamente inúteis nesse caso.
Além disso, ainda estou recebendo consistentemente um bom número de registros usando os truques do ponto e do sinal de mais no Gmail.
Abraços!
3 curtidas
Apoio a adição de uma configuração de site @codinghorror que desabilite o suporte a contas duplicadas do Gmail. Tecnicamente, é um trabalho de 15 a 30 minutos para adicionar a configuração.
4 curtidas
Obrigado @sam - Enviei uma mensagem privada com algumas informações adicionais que podem ser úteis~
Minha extensa experiência com isso ao longo dos anos é que a maioria dos spambots automatizados (não todos, mas a vasta maioria) usa a mesma string de ‘HTTP_USER_AGENT’. Até mesmo alguns bots de spam que conseguem falsificar endereços de IP frequentemente usam o mesmo ‘HTTP_USER_AGENT’ (ou algo tão falso que é fácil de detectar).
O motivo é que a maioria dos bombardeadores e spammers apenas baixa algum software de spam de bots e o executa, sem realmente saber o que estão fazendo. Sim, claro, existem exceções, mas mais de 99% dos bots de spam são apenas scripts/programas executados por spammers que não são realmente sofisticados e que baixam e executam (eles, em geral, não são gigantes da programação).
Na verdade, às vezes, essas strings de ‘HTTP_USER_AGENT’ são realmente óbvias. Claro, teoricamente tudo é possível de ser derrotado, mas na prática, em nossos fóruns ao longo das décadas, temos muito poucos problemas de spam (em comparação com outros fóruns) porque atribuímos pontuação a endereços de e-mail com base em vários critérios e rejeitamos os óbvios (não os moderamos; quando a pontuação está acima de um certo limiar {nível de confiança}, simplesmente rejeitamos o registro, porque quem quer moderar um grande banco de dados de spam? Ninguém.). Além disso, não usamos Akismet por uma série de razões (há muitos e muitos anos), mas não quero me desviar do assunto sobre esse tópico 
No entanto, em nossos antigos fóruns vB, tudo isso é feito facilmente em um plugin PHP, que é muito fácil de modificar (e lutar a boa luta) em tempo real. Em certo momento, usamos um Classificador Bayesiano, mas encontrei maneiras melhores ao longo dos anos. Também já usamos cookies e permitimos apenas registros de clientes que aceitaram a política de cookies (e permitem cookies, conforme nossa política de privacidade), e, claro, podemos ler um cookie após um usuário se registrar e usá-lo para detectar múltiplos logins. Isso, francamente, para a maioria dos spambots. Não é ciência de foguete e, francamente, geralmente não é “baseado apenas em endereço de IP”.
Além disso, FYI, a maioria dos bots de spam não aceita cookies de forma alguma, então apenas bloquear clientes que não permitem cookies ajuda muito.
Não quero parecer muito “esperto”, mas faço isso há mais de duas décadas, tenho artigos acadêmicos publicados sobre o tema, lutei em guerras cibernéticas em tempo real nesta arena e tenho mais de 20 anos de experiência em defesa cibernética em tempo real e técnicas antispam, então sei do que estou falando; portanto, por favor, não seja pesado e bloqueie minha resposta se esse tipo de funcionalidade não estiver disponível, planejado ou facilmente codificado no aplicativo Discourse, obrigado.
Vamos ser inclusivos com todos, especialmente especialistas dispostos a ajudar os usuários.
Um abraço.
2 curtidas
… 30 segundos depois …
