5 ms·
A big problem not addressed when not using a signature based authorization scheme is that you need to hit your database for every access attempt. This makes you
by conradludgate 2y ago
A big problem not addressed when not using a signature based authorization scheme is that you need to hit your database for every access attempt. This makes you much more susceptible to ddos attacks.
You need to be able to turn away malicious users as fast as possible. If you take the time to check a database first, that's a precious resource they can consume.
"Add a cache!", you might say? What if they use random client id and client secret for every request, how do you cache against that?
- candiddevmike 2y agoThe client ID should be a primary key or some other indexed value, making those database hits fairly cheap. You'd also typically have some kind of rate limiting.
- Y-bar 2y agoWe use a rate-limiting rule in the existing firewall on the /auth endpoint. Our default is on five failed attempts in a five minute window gets you a one hour ban.
- dclowd9901 2y agoHow do you fingerprint the requests? IP address?
- tebbers 2y agoThe problem I had with IP address fingerprints is that we have a large number of customers all behind one hospital’s single IP address.
- Y-bar 2y agoTwo ways, default key is [IP address + User ID] we also have a fallback with a higher limit on [IP address] only when we expect lots of attempts from e.g. a VPN.
- moduspol 2y agoThe issue from parent comment is that it needs to be on every access request, not every login request.
- dncornholio 2y agoHow do you think people make applications if every database call is suspectible to ddos?
- EthanHeilman 2y ago1. Authenticate using signed JWTs at the edge via something like AWS API Gateway. 2. If the attacker is smart enough to use valid JWTs from IDPs. Find the JWTs that match the DDoS attack and ban those identities at the edge. This rate limits the attacker to how quickly they can generate new accounts on say gmail or azure. 3. If the attacker is can generate new accounts fast enough, add a bloom filter to the edge of accounts you have seen before the attack started. At some point the attacker either gives us or just switches to the brute force of flooding the pipes with so much traffic that the AS doing the filtering goes down. At that point it is now someone else's problem. They might start de-peering the ASes generating the traffic.
- tptacek 2y agoThe article talks about when and how requests hit the database in both schemes, extensively.