Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subscription bombing and how to mitigate it

bytemash.net

Post reply on HN
Print view View original

41–50 of 199 posts

Re: Subscription bombing and how to mitigate it

#41

Post by xwowsersx »

cuu508 wrote: post #26
colesantiago wrote: post #20

Earlier quoted context omitted.

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.

It sounds appealing at first because it flips the trust model... instead of the service initiating contact the user proves control of their email up front That feels cleaner and arguably more robust against certain classes of abuse

But from a UX standpoint its a nonstarter

Youre asking users to

- leave the site/app

- open their email client

- compose a message or at least hit send

- wait for a reply

- then come back and continue

Thats a lot of steps compared to enter email -> click link. Each additional step is a dropoff point especially on mobile or for less technical users. Many people dont even have a traditional mail client set up anymore, they rely on webmail or app switching which adds even more friction

It also introduces ambiguity

- What exactly am I supposed to send

- did it work

- What if I dont get a reply

From the service side youre trading a simple well understood flow for a much more complex inbound email processing system with all the usual headaches (spoofing parsing delivery delays spam filtering)

In practice most systems optimize for minimizing user effort even if that means accepting some level of abuse and mitigating it elsewhere. A solution that significantly increases friction... no matter how principled...just wont get adopted widely

So while the idea is interesting from a protocol design perspective its hard to see it surviving contact with real users

Re: Subscription bombing and how to mitigate it

#42

Post by imiric »

znnajdla wrote: post #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 t…

So your solution is to deploy a black box that can be worked around with a basic lookup table for a single field?

CAPTCHAs were never meant to work 100% of the time in all situations, or be the only security solution. They're meant to block lazy spammers and low-level attacks, but anyone with enough interest and resources can work around any CAPTCHA. This is certainly becoming cheaper and more accessible with the proliferation of "AI", but it doesn't mean that CAPTCHAs are inherently useless. They're part of a perpetual cat and mouse game.

Like LLMs, they rely on probabilities that certain signals may indicate suspicious behavior. Sophisticated ones like Turnstile analyze a lot of data, likely using LLMs to detect pseudorandom keyboard input as well, so they would be far more effective than your bespoke solution. They're not perfect, and can have false positives, but this is unfortunately the price everyone has to pay for services to be available to legitimate users on the modern internet.

I do share a concern that these services are given a lot of sensitive data which could potentially be abused for tracking users, advertising, etc., but there are OSS alternatives you can self-host that mitigate this.

Re: Subscription bombing and how to mitigate it

#43

Post by steezeburger »

znnajdla wrote: post #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 t…

This doesn't seem like a very good solution to be honest. And why use an LLM for this? What if I want a legit random ass string as my username?

Re: Subscription bombing and how to mitigate it

#44

Post by whatevaa »

cuu508 wrote: post #26
colesantiago wrote: post #20

Earlier quoted context omitted.

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.

"The user just needs to be careful not to step on a landmine. Exact steps left as an exercise to the reader".

Anybody can send email with all of the dmarc stuff, how do you "be careful" with spoofed email?

Re: Subscription bombing and how to mitigate it

#45

Post by jaggederest »

grey-area wrote: post #16
mads_quist wrote: post #10

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).

They often do actually ignore truly hidden fields (input type=hidden) but if you put them "behind" an element with css, or extremely small but still rendered, many get caught. It's similar to the cheeky prompt injection attacks people did/do against LLMs.

Re: Subscription bombing and how to mitigate it

#46

Post by gib444 »

pqdbr wrote: post #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 for…

Ouch. Just one credit card change per account?

This is one of those levels of monitoring that only gets put in place after such an event. Eg whole subsystem analysis - the change card feature being used 1000s of times (well, proportional to scale) in 7 hours is a massive red flag

Re: Subscription bombing and how to mitigate it

#47

Post by jb1991 »

One thing I have never understood in this current age is how in the world so many companies, including ones that handle confidential data like banks, don’t require a user to verify their email address after it’s entered. I have an unfortunately very generic email address that’s easy to mistype, and I am almost every day receiving order receipts for expensive vacation hotels, bank transfer or wire transfer confirmations, a very long list of things that I should not be receiving simply because the companies sending those emails never had the user verify if they entered the right email address. They are legitimate emails, they are often addressed to someone with the same first name as me but a different last name, so that person simply typed the wrong email address accidentally.

It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.

Re: Subscription bombing and how to mitigate it

#48

Post by chw9e »

This happened to me several years ago. I got signed up to probably 700 newsletters overnight. In the middle of all of the sign ups there was activity on my airbnb account where my notification settings were changed. when i checked my airbnb i noticed that someone had created a fake listing under my account and disabled booking notifications for it. a real multi-layer scam where the hacker would be making money off a fake listing on someone else's account who would probably never even realize it.

Re: Subscription bombing and how to mitigate it

#49

Post by mfi »

I work the email security company xorlab[0], where my colleagues and I did a thorough analysis of real subscription/email bombing waves that we saw at our customers[1].

Here are some interesting additional information from the attacks we analyzed:

* Email bombing as a service is a thing, where you can buy 10,000 credits for $10 and easily bomb target inboxes with over 2000 emails per hour.

* Most all email bombing attacks starts in the morning, between 8-10.

* Most common day of attack is Friday

[0] https://www.xorlab.com/en/

[1] https://www.xorlab.com/en/blog/from-chaos-to-control-insight...

Re: Subscription bombing and how to mitigate it

#50

Post by jeroenhd »

msephton wrote: post #30

How can an affected user recover from such an attack?

Report all received emails as spam, add a filter to get rid of the @domain.com emails, and probably add the entire service to the blacklist so it doesn't happen again. Probably get rid of any paid account on that service one might have laying around.

If the email is targeted at a domain using mail servers from any major email provider (Gmail, Outlook), the user will probably find most emails into their spam folder anyway and the sending domain will get added to the spam list automatically. Especially if the attack hits multiple users on the same email service.

Post reply on HN