3 ms·

I think the part you're not addressing is the fact that DDOSers aren't using their own hardware and more importantly: their request still goes through at the en

I think the part you're not addressing is the fact that DDOSers aren't using their own hardware and more importantly: their request still goes through at the end so what do they care if it took 2000ms longer? I actually do like your puzzle challenge idea from an obfuscation standpoint of making an API less attractive for clients that aren't your own, though. A challenge system + an annoying format like Protobufs instead of JSON is too much work for a lot of abusers. Biggest problem with DDOS though is that if the volume is even reaching your application server, you're probably hosed.

scotty79 3y ago
> their request still goes through at the end so what do they care if it took 2000ms longer? It means that on this hardware they can make one request per two seconds not thousands per second. And it affects all of the hardware under the control of an attacker, so his attack becomes thousands times less dangerous. > Biggest problem with DDOS though is that if the volume is even reaching your application server, you're probably hosed. That's why I'm suggesting that challenge generation and validation can be done on separate machines. So your application servers can be safe. Obfuscation is a valid point too. I thought about it for a bit, made some experiments. Now I think the challenge should be completely random but the server needs to keep track of recently issued challenges and solved challenges to prevent reusing of already calculated solutions. I think bloom filters would be perfect for that because some small percentage of false negatives doesn't matter.