| ▲ | m132 9 hours ago |
| 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 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... |
|
| ▲ | pverheggen 8 hours ago | parent | next [-] |
| I wouldn't call this "known security issues", it's an inherent problem with any signup or forgot password page. 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. |
| |
| ▲ | jijijijij 2 hours ago | parent [-] | | > 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 service wouldn't be involved in the first place.) Now, it would slightly increase friction and lower convenience. That's why it's not done. It's inherently incompatible with dark patterns, data collection and questionable new user acquisition, but this too could be solved through standards and integration - without making Cloudflare de facto infrastructure necessity! Possible convenient, better solutions: Have the browser send this mail, either by passing a template to the mail app, integrating SMTP into the browser/addon, or instate a novel authentication protocol, which in fact may remove the human interaction completely. As if 2FA security was the main motivation for asking for email, and/or phone anyway. Companies want user IDs, if possible UIDs, as soon as possible to increase user data value and gain marketing opportunities. I once had a "welcome mail" after typing in the address, before sending the form. Yeah... | | |
| ▲ | bigDinosaur an hour ago | parent [-] | | Nothing with email can ever be an easy fix, although the idea is amusing. It is inherently the problem. | | |
| ▲ | jijijijij 26 minutes ago | parent [-] | | '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. |
|
|
|
|
| ▲ | stingraycharles 9 hours ago | parent | prev | next [-] |
| So your solution would be to do nothing? 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. |
| |
| ▲ | nmcfarl an hour ago | parent | next [-] | | But cloudflare is also just difficult, I’m on Starlink (because where I am my only other option is Hughes net), and my browser of choice is Safari. No vpn, and only boring ad blockers. I routinely blocked by Cloudflare from viewing things and occasionally, I am blocked from buying things. Just this weekend, it was $100 worth of athletic wear. I just keep clicking the box and it never lets me complete the purchase. After the 7th or 10th time I go and find another vendor that would actually sell to me. I was more annoyed than usual because the website already had my credit card at this point – but as this article proves there are reasons to block an order even with a credit card. | |
| ▲ | nottorp 2 hours ago | parent | prev | next [-] | | Cloudflare is becoming a single point of failure. That is not a solution. And these people weren't validating the email address on signup. To "reduce friction" i guess. | |
| ▲ | sdevonoes 6 hours ago | parent | prev [-] | | Cloudflare is not the solution | | |
| ▲ | stingraycharles 6 hours ago | parent [-] | | What is a better solution? | | |
| ▲ | sarchertech 4 hours ago | parent [-] | | 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. | | |
| ▲ | HumanOstrich 3 hours ago | parent [-] | | 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. | | |
|
|
|
|
|
| ▲ | siruwastaken 5 hours ago | parent | prev | next [-] |
| I fully agree with your comment. Wouldn't it be possible to just put off sending welcome emails until the user actually engaged with the product in some way? And if an account wigh no engagement persists for more than say three months just delete the account again under the premise of 'eroneousely created'? |
|
| ▲ | AndroTux 6 hours ago | parent | prev | next [-] |
| I had a similar issue and evaluated alternatives. Sadly, there were none that did the job well enough. 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. |
|
| ▲ | recursivecaveat 7 hours ago | parent | prev | next [-] |
| Since they updated the flow to only ever push 1 email to unverified users, I would say that's as patched as it can realistically be before you bring in the captchas. |
|
| ▲ | colesantiago 8 hours ago | parent | prev | next [-] |
| And your solution is assume everyone on the internet is a good actor? How would you solve this at scale? |
| |
| ▲ | RobotToaster 7 hours ago | parent | next [-] | | Op basically said that the firewall rules and email confirmation alone would've mostly mitigated this. But also Anubis is a good alternative to slow bots. | |
| ▲ | cuu508 8 hours ago | parent | prev [-] | | 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. | | |
| ▲ | whatevaa 8 hours ago | parent | next [-] | | "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? | | |
| ▲ | __david__ 6 hours ago | parent [-] | | > 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. | | |
| ▲ | habinero 3 minutes ago | parent [-] | | 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. |
|
| |
| ▲ | red_admiral 6 hours ago | parent | prev | next [-] | | That is how you get your conversion rate to drop to the floor, sadly. Every extra field in the sign-up form already lowers the conversion rate. | |
| ▲ | xwowsersx 8 hours ago | parent | prev | next [-] | | 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 | | |
| ▲ | cuu508 5 hours ago | parent | next [-] | | 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 | | |
| ▲ | williamdclt 3 minutes ago | parent [-] | | `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. |
| |
| ▲ | __david__ 5 hours ago | parent | prev [-] | | > 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. |
| |
| ▲ | grufkork 7 hours ago | parent | prev [-] | | Amidst all the age verification and bot spam going on, anonymous private/public key proof of identity could work: the newly signed up service must pass a challenge from the mail server to prove the user actually intended to sign up. Though I guess that would be basically the same thing as the users server initiating the communication. Really, just an aggressive whitelist/spam filter that only shows known senders solves it too, but as I understand part of the attack is having already compromised the mail service of the target. Having a third decoupled identity provider would resolve that, but then that becomes a single point of failure… |
|
|
|
| ▲ | aaron695 3 hours ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | AussieWog93 9 hours ago | parent | prev [-] |
| Honestly I really like CloudFlare as a business. There's no vendor lock-in, just a genuine good product. 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. |
| |
| ▲ | AndroTux 5 hours ago | parent [-] | | Then you're not using any of their services besides DNS, at which point you don't need to use Cloudflare at all. 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. | | |
| ▲ | thisisnow 5 hours ago | parent [-] | | I think they also lock you into their DNS when you buy a domain from them, unlike other registrars who allow to change your NS freely. Sure, you can just transfer the domain elsewhere for a small price, but the point is they go the extra mile to force their NS, which I havent seen with other registrars. |
|
|