Live data from Hacker News

Subscription bombing and how to mitigate it

bytemash.net

21–30 of 199 posts

Re: Subscription bombing and how to mitigate it

#21

Earlier quoted context omitted.

You add "hidden" inputs to your HTML form that are named like "First Name" or "Family Name". Bots will fill them out. You will either expect them to be empty or you fill by JavaScript with sth you expect. It's of course reverse-engineerable, but does the trick.

Thanks, I’ve seen scripted attacks bypass this sort of hidden input unfortunately (perhaps human assisted or perhaps just ignoring hidden fields).

Sure, it's really basic of course.

Re: Subscription bombing and how to mitigate it

#22
I absolutely refuse to use BigTech gatekeepers or useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by running names through a simple LLM filter - if the name is gibberish like Px2846skxojw just block the signup. Worked surprisingly well. Of course this is easy to get around if the bot knows what you’re doing. But bots look for easy targets, as long as there are enough vibe coded crap targets on the internet they’re not going to bother with circumventing a carefully designed app.

Re: Subscription bombing and how to mitigate it

#23

I absolutely refuse to use BigTech gatekeepers or useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by running names through a simple LLM filter - if the name is gibberish like Px2846skxojw just block the signup. Worked surprisingly well. Of course this is easy to get around if the bot knows what you’re doing. But bots look for easy targets, as long as t…

Nice.

Re: Subscription bombing and how to mitigate it

#24
I was attacked in this way a couple of months back. I use a different email address for each account (of the pattern product@example.com), and use a separate address for Git commits (like git@example.com). It was this second one that was attacked and I ended up with some 500 emails within 12 hours. Fortunately, since I don't expect anyone to actually email me on the Git address, I just put up a filter to send them all to a separate folder to go over at my leisure.

After 12 hours, the pace of emails came to a halt, and then I started receiving emails to made up addresses of a American political nature on the same domain (I have wildcard alias enabled), suggesting that someone was perhaps trying to vent some frustration. This only lasted for about half an hour before the attacker seems to have given up and stopped.

Strangely, I didn't receive any email during the attack which the attacker might have been trying to hide. Which has left me confused at to the purpose of this attack in the first place.

Re: Subscription bombing and how to mitigate it

#25
post #17

Earlier quoted context omitted.

It sounds like cuu508 didn't want the post-verification welcome, as opposed to the one-time verification message.

Correct.

Yes, correct. When I clicked the link I was already welcomed by the welcome page (which is, for the most part, welcomed). But then why send me another email further welcoming me? I already feel welcomed! And don't give me any of that "because it works" BS (even though that is what you are going to say).

(cuu508, "you" in this instance does not mean you)

Re: Subscription bombing and how to mitigate it

#26
post #5

It's a problem, but I really dislike the solution. Putting a website with known security issues behind Cloudflare's Turnstile is comparable to enforcing code signing—works until it doesn't, and in the meantime, helps centralize power around a single legal entitiy while pissing legitimate users off. The Internet was carefully designed to withstand a nuclear war and this approach, being adopted en masse, is slowly turn…

And your solution is assume everyone on the internet is a good actor? How would you solve this at scale?

How about a signup flow where the user sends the first email? They send an email to signups@example.com (or to a generated unique address), and receive a one-time sign-in link in the reply. The service would have to be careful not to process spoofed emails though.

Another approach is to not ask for an email address at all, like here on HN.

Re: Subscription bombing and how to mitigate it

#27
Recently we suffered a different kind of subscription bombing: a hacker using our 'change credit card' form to 'clean' a list of thousands credit cards to see which ones would go through and approve transactions.

He ran the attack from midnight to 7AM, so there were no humans watching.

IPs were rotated on every single request, so no rate limiter caught it.

We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.

We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.

Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.

We never thought this could bite us this way.

Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.

Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.

This is a big deal. Payment processors can ban you for allowing this to happen.

Re: Subscription bombing and how to mitigate it

#28
post #14

This post was written by AI, there are multiple clues. Author, why can you not use your own words? I am not sure what you meant to say, vs what is LLM garbage I could have prompted myself.

I am quite confident that the following was NOT LLM:

> New users were signing up but not doing anything, they weren’t creating an org, a project, or a deployment, they just left an account sitting there.

Surely the LLM version is:

> New users were signing up but not doing anything; they weren't creating an org, a project, or a deployment—they just left an account sitting there.

Re: Subscription bombing and how to mitigate it

#29

I absolutely refuse to use BigTech gatekeepers or useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by running names through a simple LLM filter - if the name is gibberish like Px2846skxojw just block the signup. Worked surprisingly well. Of course this is easy to get around if the bot knows what you’re doing. But bots look for easy targets, as long as t…

Using an LLM for this seems excessive when there are well established algorithms for detecting high entropy strings.
Post reply on HN