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

151–160 of 199 posts

Re: Subscription bombing and how to mitigate it

#151

Post by williamdclt »

__david__ wrote: post #111
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…

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

> It’s different

Ignoring the fact that mailto won't work for most people (it opens my Mail app which i never used), "different" is enough to make your conversion rate tank. It'd be unreasonable for anyone in charge of making product decision to go with that

Re: Subscription bombing and how to mitigate it

#152

Post by habinero »

__david__ wrote: post #111
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…

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

Ok, and a lot of -- maybe most -- people won't have their mailto handler set up correctly. I don't even know if I do on my current laptop and I have email old enough to vote

Mailto links are not that common these days.

Re: Subscription bombing and how to mitigate it

#153

Post by dpkirchner »

withinboredom wrote: post #139
HumanOstrich wrote: post #120

Earlier quoted context omitted.

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…

A $150 hold would clearly be noticed by the victim, so the attacker wouldn't even try it.

Maybe if my bank emailed me, otherwise I doubt it. Local gas stations routinely use $200 holds and I'd have to go way out of my way to see it happen.

Re: Subscription bombing and how to mitigate it

#154

Post by jamiemallers »

m132 wrote: 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…

[dead]

Re: Subscription bombing and how to mitigate it

#155

Post by dylan604 »

gregoriol wrote: post #122
shaky-carrousel wrote: post #64

Earlier quoted context omitted.

Well, what you can do is notify the card issuer about those cards that went through, so they can mark them as stolen. That surely will make the hacker really happy, and discourage them of doing it again :)

So you mean you are keeping full card numbers somewhere in your logs to... fix some potential security issue...?

I'm assuming there were transaction IDs provided that can be given to the processor. If they can't do anything with the IDs, then that's a pretty broken system.

Re: Subscription bombing and how to mitigate it

#156

Post by dylan604 »

williamdclt wrote: post #148
AndroTux wrote: post #91

Earlier quoted context omitted.

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

thousands of $1 charges and refunds in a 7 hour period seems unusual to me. then again, i've never run a site that received thousands of charges ever, so seeing it in a few hours would be obvious.

Re: Subscription bombing and how to mitigate it

#157

Post by dylan604 »

eru wrote: post #77
gib444 wrote: post #46

Earlier quoted context omitted.

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

> This is one of those levels of monitoring that only gets put in place after such an event. For a website, yes. But honestly the credit card people and their infrastructure should probably _also_ watch out for this. They'd be in a much better place to detect these.

Yeah, it seems like the site's processor should have noticed this one site sending thousands of $1 charges and refunds in a small window much more easily than the site recognizing it was being done. The processor has much more to loose multiplied across all customers making it worth their time

Re: Subscription bombing and how to mitigate it

#160

Post by bstsb »

rs_rs_rs_rs_rs wrote: post #67
steezeburger wrote: post #43

Earlier quoted context omitted.

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?

You're not owed anything, you can take your legit random ass string username to another company that allows it. I suspect any company would take this trade off, losing some customers but significantly lowering fraud.

then you have the bot picking Xbox-esque usernames like BluePanda72 instead
Post reply on HN