Stop bots to signup in app

[design.agx]

Hey there!

I have a client’s that’s been under attack in multiple occasions.

Someone is creating a lot of accounts in the app and they are bypassing few security measures I put in place.

We are using Cloudfare and have the bots fight mode activated. Cloudfare has manage to stop lots of requests but some of them are still managing

In our signup page we have Cloudfare Turnstile

Then we have email verification.

In this step, the bots were sucked but recently they have managed to verify their email

Then I have a SMS verification step using Twilio.

This is where all the bots never pass, but they manage to hurt the app by abusing the sending SMS code flow. Twilio charges money for each

I have limited the amount of a user to receive a SMS code to 1 But still, if lots of bots come through the expenses will grow

I thought also to use a app variable for limiting the SMS are sent per day. But if bots are constant, the limit will be reached fast I think

Ideally I would like to avoid bots to signup, but seeing Turnstile from Cloudfare is not fully helping, what other choice I have?

Thanks anyone for your time!

[senecadatabase]

You can use Cloudflare’s full bot mode protection. But that’s under the business plan, and I don’t know if you or your client wants to spend a couple of hundred dollars a month for that plan.

A couple of things we’ve done in the past…although not in Bubble, but they would still work.

Do you know what a honeypot is?

It’s a field in your form that is invisible to a real user, but a bot will read it because bots only read the HTML on a page.

So, you create a field and ask for something not even needed, like a fax number or something mundane. You hide it using CSS. Don’t hide it by clicking ‘invisible on page load’ because then it won’t work. When you hide it using CSS, the user won’t see it, but the bot will read it and fill out the field.

Then, in your workflow, you can check if the field is filled out and block the process if it is. This is a free method you can try.

You can also use a service like IPStack, which is pretty cheap, and connect it by API. It gives a lot of protection against repeated IPs.

You can also try ZeroBounce, which verifies emails. Most bots use burner email addresses, and ZeroBounce checks for verified emails, etc.

I was going to suggest reCAPTCHA v2, where the user does a puzzle or something. But if the bots are getting past Turnstile, then they’d probably bypass that also. You should also make sure your signup workflow isn’t publicly exposed because it seems the bots are going right to your endpoint?

Just a couple of ideas you can try.

Added: One last thing I forgot to mention, you can try.

You can download a plugin that retrieves the IP address and store it in the database, then check to see if that IP has been used within the last few minutes, or for however long you specify.

[emir.ozgun]

So What would you do lets say you are the guy that is getting attacked ?

[senecadatabase]

Are you asking me?

I would use Cloudflare’s full bot protection.

If I didn’t want to spend the extra money, I’d probably use a plugin to get the IP and check that in the signup process. However, that isn’t always 100% effective because bots can change their IP addresses numerous times.

And, I’d use the honeypot method as a backup. The honeypot method can be very effective in a lot of cases…although sophisticated bots can still bypass that. But it’s an added security measure.

The 2 sites I mentioned would also work. The only thing I have about checking email addresses is sites that require a work email. xxxx@yourbusiness.com. I think this discourages some users because I don’t even like to use a business email if I just want to try something out and see how it works because of all the spam you usually start getting with some sites.

But the best method is the Cloudflare full bot protection mode.

[emir.ozgun]

Yeah business email thing not applicable, so cloudfare, noted

[tgotchi]

It looks like the abuse is severely impacting your site.

The Cloudflare Turnstile should be working fine in most cases. Have you analyzed the traffic using tools such as ip2location.io to see the overall patterns? For example, is it from residential proxies? From there, we can plan a better filtering strategy.

[design.agx]

Thanks for the advice @senecadatabase !
Indeed, my client does not want to spend more on Cloudflare for the moment. I will try the input honeypot plus storing the IP adress.
I’m still impressed that bots can bypass Cloudflare Turnstile, hopefully, that and the honeypot input will be enough

[emir.ozgun]

To be honest, not business email but just do a research and get 100-200 at most, widely used email providers and list that on a state, then intersect them don’t allow else it will be fine

[senecadatabase]

@design.agx

I’m still impressed that bots can bypass Cloudflare Turnstile

If you ever look into how modern bots operate, it’s not surprising they can bypass it. Turnstile does good for a lot of bots, but for the sophisticated ones, it doesn’t stop.

If you look at a company like Uber, they have very advanced fingerprinting. They also have a human fraud department with analysts who personally review for bots.

If you’re not going to use the full bot protection from Cloudflare, you really should have multiple defenses.

So, the honeypot method is good, the IP address blocking method is good…

also, having Google signup/login, etc., is very good.

I use Google signup/login on my app, and I wish that were all I had to use. But you still have people using Yahoo Email and other off-the-wall emails these days.

Myself I don’t think signing up with Facebook is all that great because that platform seems to be bot heaven. We quit advertising on there because of that. Yes, there are ways you can minimize the bots, but I don’t feel like taking the time to do it because I don’t see the worth anymore.

You see a lot of apps that use phone signup/login these days. This is a great way to stop bots. The only problem is, and you’ve probably seen this on some sites, VOIP numbers are blocked for better bot protection. This can be good and bad for a number of reasons. Anyway, I wish Bubble would offer that natively. Don’t know if they do on the mobile builder side because I haven’t used that yet.

I don’t know what your app is, but if it’s a local app or one that is not international, you can go to your Cloudflare settings and block IPs from other countries. It’s still not 100% effective, but it’s another layer of protection. But if you have an international app, that wouldn’t work.

Anyway, good luck with blocking the bots

Added: Forgot to mention. Besides Google Sign Up, Apple, X, and others can be great ways to help block bots.

Added: One last thing, I promise, because I have to get to work

If the site has paid features, you can ask for a credit card upfront and deduct a small amount, such as 1 cent, or the equivalent in your local currency, and then refund it. A lot of companies do this to fight bots. There’s always the age-old debate about whether to ask for a credit card or not. It’s a valid debate, but something you can always test. Myself I don’t think it stops serious people who are genuinely interested…but that’s a debate for another time.

[anitasimaza]

If the site requests credit card information at sign-up but doesn’t charge 1 cent (or another amount), would you know if this would still deter bots? I’m building an app with membership tiers that include a 1-month free trial, and I’m planning to collect card information upon sign-up

[senecadatabase]

So when I added the part about the credit cards this morning, I was in a hurry, so let me explain further…

first, no, if you don’t take a small fee off bots can bypass that because they can use an algorithm that can create card numbers.

Now, the credit card thing should only be used if you are a recognizable brand. Netflix, Spotify, etc. Or, if you’ve been in business and have built up a trust level.

If you’re a startup and asking for a credit card out of the gate, it is going to hurt you badly. That is a terrible practice. You will lose approximately 75% of users (according to recognized tests) who would have given your app a try. One of the biggest things users are afraid of is giving their card, then cancelling, and still being charged for months after. Yes, you can go to the bank and stop the charges, but there is usually a fee, plus all the hassle.

At my bank, I can create multiple cards with different numbers to use and stop them at any time. Not all banks have this, but it’s a good feature if buying something online, etc.

I don’t know what the OP’s app does or what business it’s affiliated with is why I was throwing out all the possibilities.

So, if you’re a startup or a company that hasn’t built up trust, then you should use the other methods I mentioned.

[anitasimaza]

Thank you so much! I will rework the collection of credit card data Just one more question - it’s quite common in my industry to use 2FA (especially with the authenticator app), it’ll probably be the easiest one to add to my site which will be accepted by users. Would you know if bots could bypass it? As email workflows seem to be the most fragile, I’m thinking bots could bypass 2FA with an email verification but maybe not the other methods (and hopefully not the authenticator app!)…

[senecadatabase]

Yes, the authenticator app method is very hard for bots to bypass. It’s a good method…

however, it’s used when the user has already created an account.

The goal is to stop fake accounts from being created in the first place. Bots can create thousands of fake accounts.

As the OP stated in their post, the bots have gotten around their email verification, which they can.

So, since the goal is to first stop the fake accounts, all the methods I’ve mentioned are useful.

Some bots will attack simply to raise your expenses as much as they can. This is what the OP is worried about.

Added: Just another thought.

Security for apps, etc., is one of the fastest-growing businesses in the world right now.

I looked up a couple of statistics: Almost 300 billion worth right now. Cyber crime about 10.5 trillion annually. If it were a country, it would be the 3rd largest in the world.

A lot of attention to privacy rules, which is great, but that is user-to-user. I haven’t seen any talk from a Bubble agency about security.

Yes, that could be because most apps fly under the radar when it comes to anyone wanting to do something to them…

but, it’s something an agency could add to their business that some would find helpful if they marketed it right?

Anyway, just a thought

[anitasimaza]

Ah… got it, thank you so much! I’ll work through the options to stop bots from signing up in the first place

[senecadatabase]

Well, the main thing to keep in mind is that for most Bubble apps, they probably won’t have a problem. So, it’s not something to really panic over. It is good though to think about security before you have a problem.

If you do start having a problem, Cloudflare should be your first go-to…and also setting up a honeypot.

Here is a bot simulator I made using React:

This is going to a demo URL. You can imagine if it were going to a real URL.

A honeypot would stop those, but, and this is a big issue…it would also rack up work units.

So, just keep in mind that the methods I mentioned outside of Cloudflare are useful, but if you have a bot attack that is aimed at costing you money, you can still block them, but it may cost a lot. Cloudflare, even if you go to the next highest tier from the free version, can offer more help.

I think Flusk may have a lot of use in notifying you of things going wrong. I haven’t looked a lot into it, but I plan to.

Where I work, we work with large apps that have a lot of reasons for security concerns. But, as I said, for most apps it’s not something to panic over.

[design.agx]

A small update in this

The bots passed the honey pot input (I checked my condition was right) and I had to turn on the ‘under attack’ mode of Cloudfare.

Seems we will keep it for a while until the person stops attacking our site. In any case it doesn’t really affect our app

[senecadatabase]

Well, hopefully, you have solved the problem.

If you set the honey pot up correctly with the correct CSS to hide it, and the bots got around it, then they’re using a headless browser. This means they could also bypass your under-attack mode.

But, it makes me have a few questions about things as far as your setup and what may be trying to attack your app.

Let’s just hope everything is good now