Fixed stop forum spam email hashing doesn't seem to work

[tlamprecht]

Affected version

v2.2.13

Hello,

We got a report from a new forum user that their freshly created email alias (using the proton email provider) used to create an account on our forum quite quickly got spam and phishing messages afterwards. Something that didn't happen with other such aliases used by them.

I then checked and saw that one of our mods used the spam cleaner on their account as it was flagged due to also using an VPN with an IP that was recently reported for spam, then I wondered if StopForumSpam might have leaked it.

And indeed, after searching I found their literal email address with our forum name as user-address part in the public (!!) stop forum spam DB, but we have the "Hash emails before submission" option enabled (I just rechecked, it's still ticked), so why can this still happen and isn't this a breach against GDPR?

I mean that StopForumSpam exposes such information publicly, without account or the like required is wild, but that's a different topic and not in control of XF devs, but having the email address listed there in (unhashed) plain text was rather unexpected to say the least.

 

[ENF]

So, this hashing function has to do with checking new accounts against the SFS database. I believe it has nothing to do with when you report a spammer. The hashing protects legitimate private email address when a member joins the site. If you accidentally report someone with through SFS, you'll have to manually have to retract that with StopForumSpam staff.

That is my understanding of how this is setup and how it's documented in their API material. Please refer to 'How to Use' and 'Adding to the Database'.

At the end of the day, it's not a XenForo issue.

@Chris D - Please correct any misunderstanding if I'm wrong on XF's implementation.

 

[tlamprecht]

Thanks for your answer!

So, this hashing function has to do with checking new accounts against the SFS database. I believe it has nothing to do with when you report a spammer. The hashing protects legitimate private email address when a member joins the site. If you accidentally report someone with through SFS, you'll have to manually have to retract that with StopForumSpam staff.

Well the label and the description of that option are rather confusing then, as that reads:

If selected, the user's email address will be converted to an MD5 hash before submission

is clearly talking about submission, not just about doing so when checking against the SFS DB.

And yeah, SFS is definitively the actual place that would need to improve. For one allowing to submit hashed emails, e.g., full and the domain part so that basically all relevant checks would be still possible without compromising user PII, false positive or not (GDPR has no exception about spammers or the like IIRC). And for another any plain text mail should not be listed in public, but only accessible with API key so that scrapers have a harder time to phish any false positives.

For now, we probably have to disable SFS completely, as this is rather a grave PII leakage and thus GDPR breach.

 

[ENF]

is clearly talking about submission, not just about doing so when checking against the SFS DB.

But, it's a sub-option of 'Check new registrations against the StopForumSpam database' in Xenforo's ACP. Submission in this context relates to the process of sending the query to SFS to get a hit or not.

For now, we probably have to disable SFS completely, as this is rather a grave PII leakage and thus GDPR breach.

You can disable the submission option and keep the hashing checked for checking new accounts against SFS. Even if you use the spam cleaner after unchecking this box, data won't be reported to SFS database.

 

[Jeremy P]

We can update the wording to be a bit clearer, but indeed SFS only accepts email address hashes for checking existing records. Submitting new records requires the unhashed email addresses. You can disable submission if this is undesirable and checks will still hash the email appropriately.

 

[tlamprecht]

But, it's a sub-option

Yes, but IMO this is in the area of being technically correct, but still worse UX than it could be.
As at least I definitively don't derive such a bit subtle semantics hints from which subgroup some option is included in, especially if it talks about "submission" and the whole thing is split into "check" and "submit".

You can disable the submission option and keep the hashing checked for checking new accounts against SFS. Even if you use the spam cleaner after unchecking this box, data won't be reported to SFS database.

Yeah, that's we doing for now. I'll see if I get around to write SFS to ask if they would be interested in adding the possibility of submitting hashed emails (IMO best split into two hashes one of the full and one of the domain part, allowing to check for general bad domains and just bad addresses), which would allow more privacy aware (or restricted) forums to submit data.

We can update the wording to be a bit clearer

That would be appreciated! Maybe throw in a hint that submissions will be always in plain text and might have privacy implications (e.g. GDPR).

Thanks to both of you for your answers and clearing up that XF isn't to blame at all here.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.14).

Change log:

Clarify that new SFS submissions will transmit an unhashed email address

There may be a delay before changes are rolled out to the XenForo Community.