Signup abuse detection and blocking [Paid] 1.20.4

[smallwheels]

@Xon

it is really helpful to have this

• Add Apple Relay detection for registration spam detection (default enable, with a score of 3)

since 1.19.0 since most of my "false positives" on signup are related to that. However, I am not sure if it works in a helpful manner:

Users that come over Apple private relay on my forums typically come either via the Cloudflare ASN or via the Akamai ASN. Akamai does have a way higher scoring (4) than Cloudflare (1) - i think both are defaults. Now, instead of overruling the scoring of the ASN in question the value for Apple private relay is added on top of that, making it a especially bad offender and sending users with Apple private relay safely into moderation.

Is this the intention? Wouldn't it be a better solution to override the score for the underlying ASN and to replace it with whatever one sets as score for Apple private relay?

 

[Xon]

@smallwheels that is a good point. Next update will add the Mute any ASN score if apple icloud relay is detected option to the apple icloud relay detection configuration.

 

[Xon]

Xon updated Signup abuse detection and blocking with a new update entry:

1.20.0 - Feature & bugfix update

• Fix XF2.3.9+ & XF2.2.18 compatibility
• Update geoip2/geoip2 to v2.13, improve extendibility of who & which MaxMind database files are fetched.
• Add additional information about a login when the 2fa email is sent to the user
  • Best effort to extract the browser/operating system from the user agent
  • Add the country the login was seen from (May report "Tor" if CloudFlare is used to indicate access via Tor)
• Add Mute any ASN score if apple icloud relay is...

Read the rest of this update entry...

 

[Alpha1]

When a valid user signs up with disposable email a catch-22 occurs: We cannot approve the user, because the email is not valid. We cannot reject the user, because the user is valid. New registrations are stuck in the approval queue.
Please fix this by adding a feature to ban email domain, without rejecting the user. Force the user to enter a valid email address.

 

[Xon]

This honestly is something I'ld probably put into my multiple account emails add-on as it supports having an email state decoupled from the account state. Including having an email address explicitly marked as "invalid"

It is sadly a bit tricky on getting the relationship between account status and email status right which is why I haven't implemented this sort of thing yet over the initial hurdles of bolting on multiple email support

 

[Alpha1]

I see your point, but it seems allowing members to have multiple email accounts will make it overly complex. We dont want members to have multiple email addresses. We still need the new member to confirm their email address.

 

[Xon]

Xon updated Signup abuse detection and blocking with a new update entry:

1.20.1 - Minor feature update

• Add "Mute any Get IP Intel score if Apple iCloud relay is detected" option to apply relay detection configuration, and enable by default

Read the rest of this update entry...

 

[smallwheels]

@Xon The new iCloud-setting has already proven tobe very useful, so thanks for that!

One thing that I am wondering about: There seems to ba scoring when someone takes too long to fill out the registration for and this reults in high scorin most of the time. However: I could not find a setting for this - only one for the case that someone is too fast:



But do get these in the logs, even with decently fast registrations sometimes and strangely enough not consistent regarding the scoring and actions:

Registration form completed: 144 sec, 4
Registration form completed: 128 sec, 4.
Registration form completed: 31 sec, 4.
Registration form completed: 61 sec, accept.
Registration form completed: 54 sec, 6.
Registration form completed: 42 sec, 4.
Registration form completed: 108 sec, moderate.


So possibly there is a setting that influences it - but which setting is it?

 

[Xon]

There is a score if the application is completed too fast, but there isn't scoring for slow completion.

 

[smallwheels]

There is a score if the application is completed too fast, but there isn't scoring for slow completion.

My bad - seems to have been a misunderstanding on my side due to the "," ":" and "." in the log entries plus the occasional line break. When looking at the entry in the modqueue this seems indeed to be the Get IP Intel score that you fixed for iCloud Relay with the lastest 1.20.1 update. This is from yesterday, so 1.20.0, before the the latest version. I did falsely relate the +4 to the registration time, due to the 1 for IP thread score - misunderstanding of the entries on my side.



The log entry is a bit misleading:

Action: Moderated
Checking: xxx, xxx@xxx.net, 2a09:bxxxxxxxxxxxxxxxxx, accept. ASN matched: ASN 13335, CLOUDFLARENET - Cloudflare, Inc., US, Country detected: DE, Hostname detected: 2a09:bxxxxxxxxxxxxxxxxx, Registration form completed: 128 sec, 4. IP threat score: 1, accept. Unknown email domain: <a href="{search}" target="_blank">xxx.net</a>, Browser language: de, Browser timezone: Europe/Amsterdam, 1: Apple iCloud Relay VPN detected, Total score: 6, Moderated. Score exceeded (6 >= 6)

Possibly you could replace the "." with ":", this would make the relations somewhat clearer for the innocent. As I know the relations now no more issue for me. ;-)

 

[smallwheels]

@Xon: There seems to be a bug in 1.20.1: When iCloud relay is used, the IP Score is now set to 0 in the view but still counted towards the total:

 

[Xon]

@Xon: There seems to be a bug in 1.20.1: When iCloud relay is used, the IP Score is now set to 0 in the view but still counted towards the total:

Thanks, I'm looking into fixing it. I also noticed it isn't overriding moderate/reject rules either.

I've got a bunch of add-ons I need to update to fix some php 8.4 compatibility issues for which has taken up the rest of my bandwidth for today/tomorrow, so I should have a fix for your issue out tomorrow or the day after.

 

[Xon]

Xon updated Signup abuse detection and blocking with a new update entry:

1.20.2 - Bugfix update

• php 8.4+ compatibility fixes
• Fix "Mute any ASN/Get IP Intel score if Apple iCloud relay is detected" options didn't adjust the computed score

Read the rest of this update entry...

 

[Xon]

Xon updated Signup abuse detection and blocking with a new update entry:

1.20.3 - Bugfix update

• Fix internal server error (Unsupported operand types: int + string) that could occur depending on what exact spam check results a new account has

Read the rest of this update entry...

 

[ivp]

@Xon it would be great if you could implement the following:

1. Detect VPNs/proxies for each post, not for signup/registration only
2. Detect disposable emails using Free e-mail verification API, DISIFY, Block Temporary Email, UserCheck or similar
3. Add fingerprinting as another method for multiple accounts detection using FingerprintJS, Evercookie or similar

 

[smallwheels]

@Xon it would be great if you could implement the following:

1. Detect VPNs/proxies for each post, not for signup/registration only

As this add on is specifically about user registration I'd consider this completely out of scope. There are other add ons that serve the topic you want, namely this:

[XTR] IP Threat Monitor

Nov 21, 2025

Smart IP monitoring system protecting your forum from bots and DDoS attacks, boosting performance

• Osman
• bot blocking cache captcha ddos protection firewall ip monitoring performance rate limiting security seo
• Add-ons [2.x]

Works like a charm.

1. Detect disposable emails using Free e-mail verification API, DISIFY, Block Temporary Email, UserCheck or similar

Could be nice. However: There is already an add on that does it and plays well with this one:

[Free] UserCheck - Block Disposable Emails

May 26, 2025

Stop Spam at the Door - Block Disposable Emails Automatically

• UserCheck
• disposable disposable email addresses email spam temporary verification
• Add-ons [2.x]

As a sidenote: This one is also useful:

Resource icon X

Email domain validation

Sep 5, 2025

Add DNS checks and improve typo detection

• Xon
• email email validation validation
• Add-ons [2.x]

1. Add fingerprinting as another method for multiple accounts detection using FingerprintJS, Evercookie or similar

What are you missing currently? Are you failing to detect multi accounts with this add on? Multi account detection does (upon other things) work via longterm cookie already as far as I understand it and it does work pretty well and reliably, as far as I can judge from my experience with this add on.

 

[ivp]

As this add on is specifically about user registration I'd consider this completely out of scope.

Xon can always launch it as another add-on, but main functionality already exists in this one.

[Free] UserCheck - Block Disposable Emails

May 26, 2025

Stop Spam at the Door - Block Disposable Emails Automatically

• UserCheck
• disposable disposable email addresses email spam temporary verification
• Add-ons [2.x]

It is unmaintained.

What are you missing currently? Are you failing to detect multi accounts with this add on? Multi account detection does (upon other things) work via longterm cookie already as far as I understand it and it does work pretty well and reliably, as far as I can judge from my experience with this add on.

User simply deletes cookies and we cannot detect it as multi account.

Fingerprinting library description: "Unlike cookies and local storage, a fingerprint stays the same in incognito/private mode and even when browser data is purged".

 

[Alpha1]

It is unmaintained

No, its maintained and works. UserCheck just doesn't visit xenforo.com nor any of the other platforms it integrates with.

I've just sent a small issue and a few suggestions to the founder by email.

 

[smallwheels]

It is unmaintained.

Seems you don't know what the label "unmaintained" means and obviously you haven't even read the (pretty short) discussion of said addon (else you'd know it).

User simply deletes cookies and we cannot detect it as multi account.

Fingerprinting library description: "Unlike cookies and local storage, a fingerprint stays the same in incognito/private mode and even when browser data is purged".

Has been explained already ages ago:

@Xon, thanks for answer.

I have also some questions about multi-account detection

1. what is the mechanism of detection? just one cookie (default-userinit)? Or are there some other? Like evercookie technologies?
I mean technologies, used in evercookie (HTTP cookies + eTags +webcache HTML5 + fingers and so on) + fingerprinting
On screenshot - https://atelieraphelion.com/product...ng.64/#lg=dbtech_ecommerce_product-64&slide=1 haven't seen it. Also - in description

2. Is addon writing log somewhere in admin area? If "multi-account to thread" isn't installed? Or just to thread/conversation?

The multiple account is very simple, just a long-life cookie. This surprisingly catches a large number of offenders, and everything else tends to not be reliable or browsers let you clear it anyway. The large concern with various cache-based finger printing is you can't easy probe it for the id without polluting the cache.

The logs are in the admin area, or on the user profile. The reporting that a new multiple account is detected goes into the report system by default, but the additional "multi-account to thread" allows it to be send to threads or "multi-account to conversations" allows it to be send to conversations

Again the question: Are you using this add on and having issues or are you just spinning theories w/o haven practial experience with the add on?

 

[ivp]

Re "UserCheck - Block Disposable Emails" add-on:

The "Unmaintained" prefix is added by resource authors to indicate that they are no longer actively maintaining their resource.

We will add the prefix on their behalf should an author be inactive for a considerable amount of time, or if the external purchase URL no longer works.

My three proposals for improvement are based on more than six years of using "Signup abuse detection and blocking" add‑on.

Experience shows that the most persistent users delete cookies, making long‑life cookie detection insufficient by itself.