6 ms·

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 si

by m132 6mo 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...

AussieWog93 6mo ago
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 6mo ago
  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 6mo ago
    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.
  - AussieWog93 6mo ago
    I use their DNS and also their proxy. Both are extremely useful and good products. I assumed this is what GP was talking about when referring to the turnstile.
stingraycharles 6mo ago
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.
- sdevonoes 6mo ago
  Cloudflare is not the solution
  - stingraycharles 6mo ago
    What is a better solution?
    - sarchertech 6mo ago
      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 6mo ago
        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.
colesantiago 6mo ago
And your solution is assume everyone on the internet is a good actor? How would you solve this at scale?
- cuu508 6mo ago
  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.
  - xwowsersx 6mo ago
    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
    - __david__ 6mo ago
      > 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.
pverheggen 6mo ago
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 6mo ago
  > 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 6mo ago
    Nothing with email can ever be an easy fix, although the idea is amusing. It is inherently the problem.
    - jijijijij 6mo ago
      '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.
recursivecaveat 6mo ago
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.
AndroTux 6mo ago
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.
siruwastaken 6mo ago
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'?
aaron695 6mo ago
[dead]
jamiemallers 6mo ago
[dead]

by m132 6mo ago

AussieWog93 6mo ago

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 6mo ago
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 6mo ago
  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.
- AussieWog93 6mo ago
  I use their DNS and also their proxy. Both are extremely useful and good products. I assumed this is what GP was talking about when referring to the turnstile.

stingraycharles 6mo ago

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.

sdevonoes 6mo ago
Cloudflare is not the solution
- stingraycharles 6mo ago
  What is a better solution?
  - sarchertech 6mo ago
    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 6mo ago
      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.

colesantiago 6mo ago

And your solution is assume everyone on the internet is a good actor? How would you solve this at scale?

cuu508 6mo ago
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.
- xwowsersx 6mo ago
  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
  - __david__ 6mo ago
    > 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.

pverheggen 6mo ago

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 6mo ago
> 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 6mo ago
  Nothing with email can ever be an easy fix, although the idea is amusing. It is inherently the problem.
  - jijijijij 6mo ago
    '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.

recursivecaveat 6mo ago

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.

AndroTux 6mo ago

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.

siruwastaken 6mo ago

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

aaron695 6mo ago

[dead]

jamiemallers 6mo ago

[dead]