Hacker News Reader

Comment by conradludgate | Hacker News Reader

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?

View on HN

We 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.

How do you fingerprint the requests? IP address?

The problem I had with IP address fingerprints is that we have a large number of customers all behind one hospital’s single IP address.

Two 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.

The issue from parent comment is that it needs to be on every access request, not every login request.

The 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.

How do you think people make applications if every database call is suspectible to ddos?

1. 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.

The article talks about when and how requests hit the database in both schemes, extensively.

Reply on news.ycombinator.com