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

141–150 of 199 posts

Re: Subscription bombing and how to mitigate it

#141

Post by withinboredom »

tmarice wrote: post #137

I don't really understand the captcha hate, it's table stakes for any public-facing form. You need to pick a point on the "Ease of signup" vs. "Security" curve, and email signup + captcha seems to be the sweet spot. I haven't seen any proof that the big ones (Google, CF) can be easily and automatically bypassed, and would love to learn more if someone has evidence to the contrary.

My blog does a proof-of-work before submission (withinboredom.info) in your browser. It'll use a fair bit of cpu power, but should only take a few seconds to complete. For an attacker... that's quite slow and self-limiting.

Re: Subscription bombing and how to mitigate it

#142

Post by withinboredom »

wodenokoto wrote: post #58
jb1991 wrote: post #47

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 confirmatio…

I know e-mail has a faster round-trip, but they also don't ask you to confirm snail mail. I think it would be quite annoying to have to verify my purchase everywhere, just like how I don't wanna sign up to every single merchant online. Let me purchase as guest without having to enter OTPs.

Email isn't guaranteed to have a faster round-trip. https://groups.io/email-provider-status -- sometimes goes into hours of latency.

Re: Subscription bombing and how to mitigate it

#144

Post by veyh »

Oh, that actually explains a lot. I used to offer a 7-day free trial for one of my apps that you could sign up for with an email, and the vast majority of the licenses were never used. The app wasn't even downloaded that many times.

I stopped offering the trial since I figured it was not useful for a relatively cheap (19 EUR) app that has a 30-day money-back guarantee anyway. (It can also be used for 15 mins without a license, but requires a restart after that.)

Re: Subscription bombing and how to mitigate it

#145

Post by jijijijij »

bigDinosaur wrote: post #131
jijijijij wrote: post #126

Earlier quoted context omitted.

> I wouldn't call this "known security issues", it's an inherent problem with any signup or forgot password page. It's not inherent, though! Easy, definite fix: Reverse the communication relation. If the user has to open their mail app anyway, you could simply require them to send an email to you, instead of vice versa. This would solve the problem completely. (If spoofing the sender could be done reliably, the servi…

Nothing with email can ever be an easy fix, although the idea is amusing. It is inherently the problem.

'Inherent' has an absoluteness, which I disproved. Relying on email, is inherently troublesome, I agree.

But as I said, it's not about what's technically, or ethically mandated, but what's ensuring users won't get annoyed (getting bombed with mails is bad PR). Companies collect all these IDs for their (future) shareholders first and foremost. Asking for email doesn't alert people. Phone number would be more alarming, but that's still becoming the norm. They would ask for a picture of your passport too, but ... oh, wait!

Casually integrating Cloudflare into everything (incl. TLS termination lol), only makes data collection incentives greater. Let's not give in by declaring Cloudflare a fundamental necessity. Or do, but don't complaint about your disowned life as cattle.

Re: Subscription bombing and how to mitigate it

#146

Post by corbet »

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…

Being used to validate stolen card numbers has long been a problem; we've had to put in a number of defenses to fight our way off whatever list of "easy sites" these folks maintain. I hadn't thought about the "change card" path though...another bit of time spent away from what our business is really supposed to be doing...

Re: Subscription bombing and how to mitigate it

#147

Post by deltoidmaximus »

letier wrote: post #61
jb1991 wrote: post #47

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 confirmatio…

I have a very early gmail address. A very common first name plus two letters. It is almost unusable by now. Invoices, subscriptions, important documents about some persons real estate dealings. They all end up in my inbox. I have around 20 or 30 google accounts attached where i am the backup email address. Those people forget their passwords or stop using their accounts and i get email notifications about that. No co…

> I have around 20 or 30 google accounts attached where i am the backup email address. Those people forget their passwords or stop using their accounts and i get email notifications about that. No confirmation from my side necessary.

Does google not require a verification when you setup a backup email address?!

Re: Subscription bombing and how to mitigate it

#148

Post by williamdclt »

AndroTux wrote: post #91
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…

We solved this by introducing a silent block. If the system notices unusual behavior (too many payment attempts per user, for example), it no longer sends the payment attempt to the provider. Instead, it idles for a second or two and then just fails with a generic “payment declined.” Most attackers don’t notice they’re being blocked and just assume all credit cards are bad.

the "notice unusual behavior" is the hard part

Re: Subscription bombing and how to mitigate it

#149

Post by williamdclt »

cuu508 wrote: post #112
xwowsersx wrote: post #41

Earlier quoted context omitted.

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

`mailto` opens the Mail application on my mac, which I never ever used. I'd be surprised if that wasn't the case for most people.

Re: Subscription bombing and how to mitigate it

#150

Post by habinero »

__david__ wrote: post #86
whatevaa wrote: post #44

Earlier quoted context omitted.

"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?

> how do you "be careful" with spoofed email? You actually verify DKIM and SPF—you know, that “dmarc stuff”. That’s enough to tell you the mail is not spoofed.

Oh god. Tell me you've never dealt with those in real life without telling me lol

Usually the very best you can do IRL is "probably fine" or "maybe not fine" and that's just not good enough to justify blocking customers. Email is an old tech and there's a lot of variation in the wild.

Post reply on HN