Signup abuse detection and blocking [Paid] 1.20.7
- Thread starter Xon
- Start date
Any feature can be turned on or off. That's how pretty much all functionality works. So its a moot point.
No one wants features forced upon them. Especially not functionality that can go rogue or can be untrustworthy.
I work with AI a lot and have found that specific models within strict conditions and limitations can be very useful and effective. Especially at tasks a human does not want to do.
Doing the repetitive job of digging up blacklisting status in various databases, evaluating profile fields, digging through duplicate accounts, etc, etc. Each taking 1 - 10 minutes to get a good grasp of what's going on. That's certainly not a hobby of mine. Yet the reports pile up and I find myself procrastinating. Not doing it leads to spam attacks which is not great either.
Even having Claude Code post an evaluation to the report would help a bit.
I already have Claude analyse my server logs and CF logs, with extremely useful results. Especially in regards to attackers, spammers, scrapers and traffic analysis. It catches things I could never catch myself. Combining server and CF data with moderated registrations and duplicate accounts seems gold to me, because it WILL bring issues to your attention that you were completely unaware of before. And from experience I can tell you that some of the issues AI makes you see are simply scary. Spammers and attackers are using AI to get around our layers of protection.
No one wants features forced upon them. Especially not functionality that can go rogue or can be untrustworthy.
I work with AI a lot and have found that specific models within strict conditions and limitations can be very useful and effective. Especially at tasks a human does not want to do.
Doing the repetitive job of digging up blacklisting status in various databases, evaluating profile fields, digging through duplicate accounts, etc, etc. Each taking 1 - 10 minutes to get a good grasp of what's going on. That's certainly not a hobby of mine. Yet the reports pile up and I find myself procrastinating. Not doing it leads to spam attacks which is not great either.
Even having Claude Code post an evaluation to the report would help a bit.
I already have Claude analyse my server logs and CF logs, with extremely useful results. Especially in regards to attackers, spammers, scrapers and traffic analysis. It catches things I could never catch myself. Combining server and CF data with moderated registrations and duplicate accounts seems gold to me, because it WILL bring issues to your attention that you were completely unaware of before. And from experience I can tell you that some of the issues AI makes you see are simply scary. Spammers and attackers are using AI to get around our layers of protection.
Agreed with @Alpha1 - as long as it can be toggled on or off and adjusted, I don't see the problem. Yes, I know and have even been the victim of AI-slop with false positive bans on other platforms. But that's what makes it so much more important for us to carefully choose and test the tools we choose to implement. Nothing is bulletproof and that's the important thing to realize. But in the right hands and with the right use and moderation, certain tools CAN be helpful and very useful, it's just a matter of how much effort is put into using them, testing, and keeping an eye on it.
@Xon it would be quite useful if multiple account reports would come with a HIBP check for email and password combination.
Claude Code has been reviewing our multiple accounts reports and it turns out that its often not a case of sock puppets, but bad actor(s) mass logging in with leaked email & password combinations. Your Password Security addon is very useful for locking accounts. It would be awesome if we could fire a HIBP check from the account drop down as well.
haveibeenpwned.com
Claude also exposes quite a few multiple accounts rings that have not (fully) triggered the detector.
Claude Code has been reviewing our multiple accounts reports and it turns out that its often not a case of sock puppets, but bad actor(s) mass logging in with leaked email & password combinations. Your Password Security addon is very useful for locking accounts. It would be awesome if we could fire a HIBP check from the account drop down as well.
Have I Been Pwned: Check if your email address has been exposed in a data breach
Search tens of billions of breached records, monitor corporate domains via API, and get alerted when credentials are exposed. Trusted by security teams, MSSPs, and government agencies worldwide.
haveibeenpwned.com
My Password tools add-on already supports checking HIBP on login/registration which helps a lot. These are the code paths which actually see the password.
Maybe some integration to show if the user has the compromised password flag set in the multiple account reports could be done.
Maybe some integration to show if the user has the compromised password flag set in the multiple account reports could be done.
Xon updated Signup abuse detection and blocking with a new update entry:
1.20.6 - Bugfix update
Read the rest of this update entry...
1.20.6 - Bugfix update
Read the rest of this update entry...
It would be useful to have a LLM watermark check on post texts. Especially for new members and dormant accounts becoming active again.
Dormant accounts coming back to life is where quite a bit of bot/spammer activity takes place now. Especially those with leaked credentials.
Dormant accounts coming back to life is where quite a bit of bot/spammer activity takes place now. Especially those with leaked credentials.
What I’ve been doing lately is disabling dormant accounts with a flag that they must reset their password before they can access the account again. That’s cut down my dormant account spam by a lot.
Agreed, I do see this a lot and have actually had Claude Code work up an addon that protects my private marketplace exchange from these accounts that abuse long-time member accounts with good standing to post fake listings and scam others.
Smart move!
Xon updated Signup abuse detection and blocking with a new update entry:
1.20.7 - Bugfix & compatibility update
Read the rest of this update entry...
1.20.7 - Bugfix & compatibility update
Read the rest of this update entry...
Yup. Previously it had a strict version check but with the vast amount of back-ported security releases it had to be switched to feature detection instead.
We're preparing to upgrade Signup Abuse Detection and Blocking from 1.13.6 to 1.20.7 on a fairly large XenForo 2.2.19 Patch 2 forum running PHP 8.3. I tested the upgrade first on a recent clone of the live site. Everything completed successfully, but the MigrateLoginRecords portion took over 3.5 hours and created about 2.8 million rows in xf_sv_login_log.
I'm mainly trying to figure out the safest way to minimize how long the forum needs to be completely offline. I dug into the data a little further and about 96% of the rows being migrated are coming from historical xf_ip login records rather than signup records. From looking at the upgrade code, it appears XenForo promotes the new add-on version and then runs the Atomic job queued by postUpgrade(). I also don't see an obvious cutoff, preload check, or deduplication mechanism in MigrateLoginRecords, so I don't want to work around it myself and accidentally duplicate history.
A few questions:
1. Is it safe for MigrateLoginRecords to run while the forum is open? If so, is there anything that needs to be disabled while it runs, such as new registrations or user logins?
2. Is there a supported way for the add-on upgrade itself to finish and then let MigrateLoginRecords continue in the background through XenForo's normal job system?
3. Can MigrateLoginRecords safely be stopped and resumed, or would already completed batches be copied again?
4. Is there any way to pre-migrate most of the historical data while 1.13.6 is still running, then migrate only the small amount of new data during the final upgrade window?
5. Does the migration support any kind of date, user ID, row ID, or other starting/cutoff point?
6. If xf_sv_login_log were pre-populated, is there any supported way for the upgrade to recognize the existing rows and avoid migrating them again?
Would pruning old xf_ip history before the upgrade be a reasonable approach for a site this size? And is two years a reasonable retention period from Signup Abuse's point of view?
If there's a newer migration implementation or recommended procedure for large installations, I'd be happy to use that instead of trying to work around the normal upgrader.
I'm mainly trying to figure out the safest way to minimize how long the forum needs to be completely offline. I dug into the data a little further and about 96% of the rows being migrated are coming from historical xf_ip login records rather than signup records. From looking at the upgrade code, it appears XenForo promotes the new add-on version and then runs the Atomic job queued by postUpgrade(). I also don't see an obvious cutoff, preload check, or deduplication mechanism in MigrateLoginRecords, so I don't want to work around it myself and accidentally duplicate history.
A few questions:
1. Is it safe for MigrateLoginRecords to run while the forum is open? If so, is there anything that needs to be disabled while it runs, such as new registrations or user logins?
2. Is there a supported way for the add-on upgrade itself to finish and then let MigrateLoginRecords continue in the background through XenForo's normal job system?
3. Can MigrateLoginRecords safely be stopped and resumed, or would already completed batches be copied again?
4. Is there any way to pre-migrate most of the historical data while 1.13.6 is still running, then migrate only the small amount of new data during the final upgrade window?
5. Does the migration support any kind of date, user ID, row ID, or other starting/cutoff point?
6. If xf_sv_login_log were pre-populated, is there any supported way for the upgrade to recognize the existing rows and avoid migrating them again?
Would pruning old xf_ip history before the upgrade be a reasonable approach for a site this size? And is two years a reasonable retention period from Signup Abuse's point of view?
If there's a newer migration implementation or recommended procedure for large installations, I'd be happy to use that instead of trying to work around the normal upgrader.
Hoping @Xon gets back to you today, we have our update scheduled for tomorrow morning and these are important questions
@dougdirac this is something of a design flaw. I've got some other cleanup worka round the xf_ip migration bits. Can you open a ticket on my site so I'll likely need to share an updated build or two to fix the iteration.
Yes.
Sadly no, it would require patching the installer to push them onto a job queue for after the add-on update instead of during the add-on update
It is a standard XF job, so yes. The problem is it gets triggered as a manual job and blocks the installer.
Not sanely.
The most recent version has some options to prune these tables but that is ignored when this update is run.
This isn't supported, the migration code isn't that complex.
Pruning the old xf_ip table would be the safest way to reduce how much data it needs to touch, but I also need to update so it applies the retention policy before migrating data.