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

111–120 of 199 posts

Re: Subscription bombing and how to mitigate it

#111

Post by __david__ »

xwowsersx wrote: post #41
cuu508 wrote: post #26

Earlier quoted context omitted.

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…

> But from a UX standpoint its a nonstarter

Disagree. The UX would be pretty similar. Click a mailto link which opens the email client with to, subject and body precomposed. Click send. Server receives mail and the web page continues/finishes the sign up process. No need for an email reply. It’s different, but it’s not crazy.

Re: Subscription bombing and how to mitigate it

#112

Post by cuu508 »

xwowsersx wrote: post #41
cuu508 wrote: post #26

Earlier quoted context omitted.

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…

I think the main UX obstacle is that it is unfamiliar – no-one does signups like that currently. But the flow does not need to be quite as bad, if you use "mailto:" links. In the happy case:

- user click on the link

- their email client opens, with the To:, Subject:, Body: fields pre-filled

- user clicks "Send"

- a few seconds later a sign-in link arrives in their inbox

Re: Subscription bombing and how to mitigate it

#114

Post by duckmysick »

chw9e wrote: post #48

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…

How did they access your Airbnb account?

Re: Subscription bombing and how to mitigate it

#115

Post by jiehong »

I think it’s time to stop using emails in general for all of that.

What’s the alternative, though?

What if each service generates a link to a uuid url where all new message will be displayed? The user can rss subscribe to that.

So the user doesn’t receives anything.

Re: Subscription bombing and how to mitigate it

#116

Post by sarchertech »

stingraycharles wrote: post #84
sdevonoes wrote: post #74

Earlier quoted context omitted.

Cloudflare is not the solution

What is a better solution?

You have to think hard about the problem and apply individual solutions. Cloudflare didn’t work for the author anyway. Even if they had more intrusive settings enabled it would have just added captchas, which wouldn’t likely have stopped this particular attacker (and you can do on your own easily anyway).

In this case I assume the reason the attacker used the change credit card form was because the only other way to add a credit card is when signing up, which charges your card the subscription fee (a much larger amount than $1).

So the solution is don’t show the change card option to customers who don’t already have an active (valid) card on file.

A more generic solution is site wide rate limiting for anything that allows someone to charge very small amounts to a credit card.

Or better yet don’t have any way to charge very small amounts to cards. Do a $150 hold instead of $1 when checking a new card

As far as cloudflare centralization goes though, you’re not going to solve this problem by appealing to individual developers to be smarter and do more work. It’s going to take regulation. It’s a resiliency and national security issue, we don’t want a single company to function as the internet gatekeeper. But I’ve said the same about Google for years.

Re: Subscription bombing and how to mitigate it

#118

Post by dgellow »

Oh that’s interesting. I think that matches perfectly with an experience I had with a micro saas I run. I first thought people discovered it organically because it started with just a few signups throughout the weekend, then eventually escalated to multiple an hour. None of the accounts were active but email addresses didn’t look too odd and they weren’t bouncing. I eventually added a captcha that seems to have been effective, but that was a surprising experience because there is nothing you can use that saas for anything nefarious as far as I’m aware

Re: Subscription bombing and how to mitigate it

#120

Post by HumanOstrich »

sarchertech wrote: post #116
stingraycharles wrote: post #84

Earlier quoted context omitted.

What is a better solution?

You have to think hard about the problem and apply individual solutions. Cloudflare didn’t work for the author anyway. Even if they had more intrusive settings enabled it would have just added captchas, which wouldn’t likely have stopped this particular attacker (and you can do on your own easily anyway). In this case I assume the reason the attacker used the change credit card form was because the only other way to…

None of your solutions seem useful in this case, especially a $150 hold. Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.

You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes. Combine that with other (useful) mitigations. Maybe getting an alert that in the past few hours or days even, 90% of card change attempts have failed for a cluster of users.

Post reply on HN