The Internet was carefully designed to withstand a nuclear war and this approach, being adopted en masse, is slowly turning it into a shadow of its former self. And despite the us-east1 and multiple Cloudflare outages of last year, we continue to stay blind to this or even rationalize it as a good thing, because that way if we're down, then so are our competitors...
Also, I doubt this is going to be pissing users off since they added Turnstile in invisible mode, and selectively to certain pages in the auth flow. Already signed in users will not be affected, even if the service is down. This is way different from sites like Reddit who use their site-wide bot protection, which creates those interstitial captcha pages.
Cloudflare is an excellent solution for many things. The internet was designed to withstand a nuclear war, but it also wasn’t designed for the level of hostility that goes on on the internet these days.
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 form the subscription fee (a much larger amount than $1).
So the solution is don’t show that 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.
How do you suggest to implement bot prevention that works reliably? Because at this point in time, LLMs are better at solving CAPTCHAs than humans are.
How would you solve this at scale?
But also Anubis is a good alternative to slow bots.
Another approach is to not ask for an email address at all, like here on HN.
Anybody can send email with all of the dmarc stuff, how do you "be careful" with spoofed email?
Every extra field in the sign-up form already lowers the conversion rate.
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
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.
- 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
If they turn around later and do something evil, literally all I need to do is change the nameserver to a competitor and the users of my website won't even notice.
As soon as you turn on any other service they offer, you need to actively migrate away. It's an inherent issue of services that actually provide a benefit. If you're saying "I can just migrate to any other nameserver" then you're telling me you have no use for Cloudflare in the first place. Because if you did, you couldn't just not use it anymore.
Let's say you're using their WAF. Sure, you can just change your domain's nameserver and you've migrated away. But now you no longer have a WAF. Same for their CDN. Or their load balancer. Or their object storage. Or their CAPTCHAs.
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.
Double check that there are no forwarding rules added to your inbox and add some protection against a SIM swap.
In my case, they didn't compromise any of my accounts but did attempt to open a new credit card so it would be worth double checking your credit reports.
It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.
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.
I set up a new address that is less likely to end up with this problem. But migrating away from the old one is not easy…
I get so many other $MY_NAME emails, including bills (including multiple credit cards and things like Afterpay), deliveries, medical details/reports, family communications, etc, etc.
And it's very clear that quite a few online services blatantly don't verify email addresses, they just assume the email is valid and allow the person to start using it.
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.
Also, people usually type their emails correctly, especially these days with auto-fill. So not sending confirmation emails is optimizing for the happy path.
I have even had founder level emails that presumably are confidential sent to me because I share the name of someone operating in tech.
I respond or report when it's obviously some real person running a small group but for large monoliths there is very little to do except quickly reply to corporate email.
Really wish there was some kind of high level discussion about building something for this specific problem of non malicious wrong person same name errors.
Google could do it it's just not something that is monetizable at a scale they care about IMO and I have not been able to think of a way to make this work operating outside of email monoliths.
Would love to hear if anyone has ideas.
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...
I hope "LLM thinks your name is gibberish" won't become the new "your name can't include invalid characters".
I suspect any company would take this trade off, losing some customers but significantly lowering fraud.
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.
So, by your own admission, your solution doesn’t get around the “sufficiently advanced bot” problem.
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.
> Verify your email address > Welcome to Suga > Reset your password > Three emails they never asked for, from a product they may never have heard of. We were just one of potentially hundreds of sites being hit at the same time.
@homelessdino
Why would you send welcome and reset to some victim that DID NOT verify?
> While the victim is drowning [...] the attacker is doing something else.
In the past months some personal mail accounts on a mail server I administer were victim of something that looked similar to what's described here.
Hundreds of mails apparently originating from various (legit-looking) random public web services, support requests, issue trackers, web contact forms etc. For example, a good part of them was from Virginia Department of Motor Vehicles (as in something like "thank you for filing a document #123 with us").
To make things even weirder, they were not sent directly to the address, but according to message headers were bounced through Google Groups (each time I checked the relevant group was already deleted). So as far as I can tell it was not the mail address hosted on my server that was being entered into those websites.
No phishing links, no attached malware, no short advertisements snuck into a text field etc. Just a huge amount of automated replies from "noreply@" legit entities.
I've seen several of these attacks and spent some time investigating them. To my knowledge these were not associated with any other malicious activity, like the author of the article mentions. If anything they were just a denial-of-service attack on a mail box (as in, making the human user trawl through garbage, the mail volume was far from saturating the server itself). What exactly would be a motivation for that I can't tell, except making the life of a small mail server admin even harder than it already is.
My conclusion is to move from WordPress software as fast as possible, every WordPress site I manage gets bombarded by bots.
Now, every mofo just wants a grant to ---- innocent kids in school.
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.
As a user, I would prefer no welcome email at all.
There was a time were you would have to select "sign me up for your newsletter" then you had to uncheck it. Then you had to check to not get an email and now you don't even get that choice.
And lately? You have to go dig through your email because you can't set a password (looking at you Claude), so you can't filter email.
(cuu508, "you" in this instance does not mean you)
We added a captcha and used a disposable email checking service to get rid of it.
Editing to add: almost 100% of these emails came from the same e-commerce product, I'll have to look up which. But every site i got an email from was running the same off the shelf template.
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.
The text probably have been based entirely on the internal notes and investigations and is very informative. Would it be better if the OP wrote it entirely by themselves? Not necessarily.
Which makes is even more annoying. Because you don't know which are the good bits where somebody is sharing his unique insight, and which is just taken from the LLMs world knowledge.
Why not accept that it is good, and forget about it being 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.
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.
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
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.
JS can be reversed, you clearly see what data points they use for detection. Anything can be spoofed and it will look like human behavior.
And if everything fails, you outsource it to AI - Always Indian :D