How to deal with sign-up spam?

[dan]

I have self-service registration turned on. I am getting some valid users, but a bunch of spam accounts.

What is the best way to deal with this?

Thanks!

[dan]

You have a variety of ways to approach this, with different tradeoffs around functionality, effort and cost. It also matters if the spam accounts are being signed up for by humans or bots.

• use a webhook to prohibit bogus users from being created by setting the user.create webhook to be transactional. You'd then write a service that could examine the user object, including email address or other attributes, and return a non-200 value to fail their creation. Details on webhooks. This is available on the community plan.

• use email verification to prevent spam users without an email inbox from using your application. Details on configuring this functionality. This is available on any paid plan.

• use a self-service registration lambda, and examine the email address and other information for a user. If a user is obviously bogus or matches a pattern, you could return a message stating they can't register, or to call you for assistance. Details on using this lambda. This is available on any paid plan.

• turn on CAPTCHA which will make it harder for bots to sign up. This requires an enterprise plan.

[theogravity-sb]

There's also another kind of spam that we're noticing. At least for Google IdP accounts, scammers are adjusting their name to include malicious URLs (without even using link tags). The gmail UI will unfortunately render them as links.

Does FA have some built-in functionality to deal with this scenario?

[dan]

@theogravity-sb Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:

foo@gmail.com with a name of <Dan https://evil.com> which is being turned into a link?

Or am I misunderstanding your question?

[atakan]

@dan It is like that. They use regular /oauth2/register flow to create spam accounts. Even though we deploy WAF, it usually can't catch them as they obey the rate-limits.

[dan]

@atakan @theogravity-sb Seems like two different issues here.

@theogravity-sb is talking about attackers using the Google identity provider to create accounts with malicious names. @atakan is talking about attackers using self-service registration to create accounts with malicious names. They seem related but not identical. When you are allowing people to create their own identity and/or delegate to another source of identity, you decrease friction but give up some control.

The bad news is that FusionAuth has nothing out of the box to stop this behavior.

The good news is that you can build an integration to stop it. There are email verification services that give you a risk factor for email addresses and you can check that before you allow for registration or login.

Here's a blog post I wrote about leveraging a third-party service to check the validity of emails provided during registration. This post uses a self-service registration validation lambda, but for the Google identity provider use case, you could use the login validation lambda and perform the same type of check.

While I used Fideo because it had a good API and I had a connection there, I have not done an extensive survey of the landscape of email verification services, so cannot recommend any particular service.