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.
Ok…I thought this kind of “gmail dot and +” registration was mostly done by bots …
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.
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.
That’s already the case… the problem here is it is Mossad. They have lots and lots of IPs to use.
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.
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.
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?
Great thanks @sam and sorry I didn’t follow up on this yet.
Yes it still seems quite viable to make a lot of accounts using this trick (2.5.0.beta1).
For example, using the username+{randomstring}@gmail.com trick, someone created 748 accounts in the last 10hrs. They already have thousands of accounts on this single gmail address.
Pretty much the only way for me to be able to remove them from the admin area is manually going to each account individually to suspend and/or delete them. It’s not very viable because the guy can pretty much just press a button and make a lot more accounts.
They pretty much seem to have an unlimited supply of IPs, so IP bans/limits are pretty much futile in this case.
Also, still consistently getting quite a lot of registrations using the gmail dot and + tricks.
Cheers!
I support adding a site setting @codinghorror that disables dupe gmail account support, technically it is a 15-30 min job to add the setting
Thanks @sam - I sent you a pm with some additional info that may be helpful~
My extensive experience with this over the years is that most automated spambots (not all, but the vast majority) use the same ‘HTTP_USER_AGENT’ string. Even some of the spam bots that can fake IP addresses often use the same ‘HTTP_USER_AGENT’ (or uses something so bogus it is easy to detect).
The reason is that most bombers and spammers just pull down some bot spam software and run it and don’t really know what they are doing. Yes, of course there are exceptions, but 99+ % of spam bots are just scripts / programs run by not-really-sophisticated spammers who download and run (they are not coding giants, in general).
In fact, sometimes, these ‘HTTP_USER_AGENT’ strings are really obvious. Of course, everything is possible to defeat in theory, but in practice on our forums over the decades we have very little spam problems (compared to other forums) because we score email addresses based on various criteria and reject the obvious ones (we don’t moderate them, when the score is above a certain threshold {confidence level} we just reject the registration, because who wants to moderate a large DB of spam? No one.). Also, we don’t use Akismet
for a host of reasons (for many, many years), but I don’t want to go off on a tangent on that topic
However, on our old vB forums this is all done easily in a PHP plugin which is very easy to modify (and fight the good fight) in real time. At one time we used a Bayesian Classifier, but I found better ways over the years. We have also used cookies and only permit registrations from a client which has accepted the cookie policy (and permits cookies, per our privacy policy) and of course, we can read a cookie after a user registers and use this to detect multiple logins. This stops most spambots, frankly. It’s not rocket science and it is not generally “only IP address based”, frankly speaking.
Also, FYI, most spam bots do not accept cookies at all, so just blocking clients which do not permit cookies helps a lot.
Not to sound too “smart” but I been doing this for over two decades, have academic published papers on the topic, fought real-time cyberwars in this arena, and have nearly 20 years+ experience in real-time cyber defense and anti-spam techniques, so I do know what I am talking about; so please don’t be heavy handed and block my reply if this kind of functionality is not available, planned, nor easily coded into the Discourse app, thanks.
Let’s be inclusive to everyone, especially experts who are willing to help users.
Cheers.
… 30 seconds later…