Implement logging to a .log file of all failed authentication attempts

[quamok]

Is your feature request related to a problem? Please describe. Right now, there is no log of users authenticating to Tandoor Recipes. We cannot implement IP blocking or monitoring of failed login attempts.

Describe the solution you'd like It would be nice to create a log of all authentication, or only failed authentication attempts, to the web page.

Describe alternatives you've considered it's possible to enable authentication to the reverse proxy (nginx), but then users would need to authenticate twice.

Additional context I'd like to implement fail2ban on this new log to prevent brute forcing and account enumeration attacks.

Example of log for Bitwarden_rs [2021-04-27 22:11:45.635][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: 192.168.20.1. Username: aaa@gmail.com

Example of log for Home-Assistant 2021-04-29 16:47:14 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 193.40.29.67 (193.40.29.67). (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4429.93 Safari/536.36)

Thank you for considering and keep up the good work :)

[vabene1111]

thanks for the detailed issue. Is this way of doing it considered the standard in blocking login attempts ? because intuitively i would have implemented this as a database but that would probably make it hard for external tools like fail to ban to read it.

Do you think it is preferable to have a seperate log file or would it be beneficial if the application itself had a fail to ban feature ?

[quamok]

that's a good point regarding implementing it directly into the application. I think it would be nicer to have in integrated directly into the app. For example, Photoprism implement brute force protection by slowing down recurring failed login attempts to the point where it's so slow that it isn't worth it for an attacker to pursue the attack.

NextCloud has implemented something like fail2ban directly into the app, though I'm not sure of the exact method used. But they still log failed login attempts to a log file, so it's still possible for anyone to use something like fail2ban to fine tune brute force protection to their liking.

It's also important that the application returns the same error message when the username doesn't exist as when the user exist but the password is incorrect. This prevents enumeration attacks.

Even if something in implemented directly into the app (which would be fantastic), I think it's still good practice to log failed login attempts to a file, but that's just a personal opinion :)

As for your 1st question, I don't know if it's THE standard way to do it, but I know that fail2ban is quite popular and highly effective and used for this exact purpose.

For example, after X failed login attempts from a specific IP, you ban the IP for X seconds before that IP can try to log in again, X being defined by the user setting up fail2ban.

for reference: https://www.fail2ban.org

Thanks!

[vabene1111]

ok perfect, thanks for all the insight. I definitely need to implement something like this. The same error message thing is already in there and has always been but there is no limiting atm which is bad.

[DiversityBug]

It would be awesome if there would be a setting in the app where one could define the number of failed login attempts to prevent DDoS. Plus having a blacklist/whitelist to handle blocked IP's.

[vabene1111]

So i have just looked around a little and it seems like https://github.com/jazzband/django-axes is probably the best way. Its maintained and actively developed, seems to support some pretty solid rules for throttling and is compatible with DRF and allauth which is important

[Szeraax]

Does nginx not have a way to monitor the login request response codes (401 unauthorized) and implement the backoff/ban logic before it ever gets to the app?

Not something I've ever tried, but that's more of where I'd expect that logic to live.

[vabene1111]

django allauth already provides a certain degree of brute force protection, that should suffice for now