Comment by nine_k
3 years ago
There's a natural contradiction between security and privacy.
For security, an actor needs to be tested and marked as secure, or else tested again before every interaction.
For privacy, an actor must not be marked, lest observers could correlate several interactions and make conclusions undesirable for the actor.
It does not make the infinite loop produced by CLoudflare any more reasonable though.
Ever heard of zero-knowledge proofs?
CloudFlare claims to support Privacy Pass, which is supposed to use a zero-knowledge scheme to solve for this for Tor users.
Unforunately, the integration has been broken for a very long time and bug reports aren't tended to.
https://blog.cloudflare.com/cloudflare-supports-privacy-pass...
https://privacypass.github.io/
https://github.com/privacypass/challenge-bypass-extension/is...
I don't understand why an actor needs to be tested and marked as secure on first interaction. There must be signals so that the server could initially trust an actor in some case. For example, why can't the server trust a never before seen IP attempting to sign into an account that hasn't been experiencing incorrect password attempts? Is Cloudflare just a case of a one size fit all solution?
the problem is it's too easy to make a botnet attack a sure by having each computer try a password for a unique account once per day. this wouls let you get a few million chances per day or website at guessing user passwords without detection.
In theory, this could be countered by moving to one wrong password attempt per IP over any web site protected by Cloudflare. I have a better understanding of the threat and there might be other drawbacks.
I disbelieve there is no way for a client to prove that it has been challenged and cleared in the past without disclosing a persistent unique identifier.
Without a unique identifier, it would be easy for an attacker to clear one challenge and use the result for all nodes in a botnet.
Why can't the identifier be merely yet another bit of data whose existence and properties can be proven by cryptography without transmitting the data itself? It's done all the time with other data.
3 replies →
I'm at a loss for how this could be implemented reliably (where it never fails to stop bots). Ideas?
I don't think the burden of proof/R&D is on us. But there are many smart people around, I'm sure Cloudflare can pay some of them (even more surprising things are possible with cryptography).
One far-fetched idea is to use ZKP proofs to prove that you were verified, without disclosing anything your identity. But that's likely overkill.
Anyway, I think Cloudflare already works on something better with turnstile, the "privacy preserving captcha" and private access tokens [0].
[0] https://blog.cloudflare.com/turnstile-private-captcha-altern...
What do you see as the problem with this attempt?
https://privacypass.github.io/
2 replies →
Isn't the client's IP address a sufficient unique identifier?
Absolutely not. Dozens if not hundreds of legitimate clients can appear on the same public IPv4 address, being home internet customers behind a NAT. The same client can trivially change their IPv4 and likely IPv6 address on a mobile network by toggling flight mode to reconnect.