REJack
commented
6 years ago First of all: its not really a "DDOS"-protection. Its bascially just a Brute-Force protection preventing people from trying to call the login-function hundreds of times with different passwords/usernames. But it doesn't really reduce the server-load as it still queries the DB a few times before it decides to deny access to the script. So even if an ip is banned, it still causes quite some load on the server.
It's true that's only a BruteForce protection, but it still reduce server-load the check is in front of all user related checks.
Personally I would either remove this feature completely or rewrite it slightly. Basically i would extend the login_attempts table to include the account-id. So if an IP-address tries to access 10 different accounts i would keep track for every account independently. This way, it would still be very hard for people to brute-force usernames+passwords and people can't ban tons of other people accidently. All you got to do is move the check after the point where you query the DB for the account/user-id. Then, instead of just storing the ip, you would store the ip AND the user-id they tried to use.
I've planed for Aauth v3 that Aauth stores the used email or username in the login_attempts table too.
The DDOS-Protection is kinda problematic.
First of all: its not really a "DDOS"-protection. Its bascially just a Brute-Force protection preventing people from trying to call the login-function hundreds of times with different passwords/usernames. But it doesn't really reduce the server-load as it still queries the DB a few times before it decides to deny access to the script. So even if an ip is banned, it still causes quite some load on the server.
And what is even worse: imagine a company with 50 PCs that are all connected to the internet through the same router. For any server on the internet, all employees will have the same IP (that of the router). Now lets say they are running a webapp somewhere that uses AAuth. If one of the employees triggers the "DDOS"-protection, nobody from the company will be able to login until the ban runs out.
Personally I would either remove this feature completely or rewrite it slightly. Basically i would extend the login_attempts table to include the account-id. So if an IP-address tries to access 10 different accounts i would keep track for every account independently. This way, it would still be very hard for people to brute-force usernames+passwords and people can't ban tons of other people accidently. All you got to do is move the check after the point where you query the DB for the account/user-id. Then, instead of just storing the ip, you would store the ip AND the user-id they tried to use.