Log authentication attempts when PASSWORD environment variable is used

Description

Background: It’s possible to enable password authentication to access the dashboard using the PASSWORD environment variable. If you try to authenticate with the wrong password you will be met with an error message, but nothing related to the authentication attempt will be logged.

Suggestion: Have Homarr log authentication attempts when the PASSWORD environment variable is used.

The log could be of similiar form as Sonarr, Radarr and Lidarr:

2022-11-14 15:00:00.0|Warn|Auth|Auth-Failure ip 123.123.123.123

To prevent log clutter or endlessly growing logs, one could use rotating logs or a daily cut-off point as in the case of the *arr apps. Logs older than a certain threshold could be culled with a simple cron job. For those with privacy concerns or certain threat models, logging could also be disabled with a boolean. In my mind, a docker compose with these features would look something like this:

...
- PASSWORD=SuperSecretPassword
- ENABLE_AUTH_LOG=true
- KEEP_AUTH_LOG=720h # 30 days, only necessary if ENABLE_AUTH_LOG=true
...

I believe this feature would help users become more aware of authentication attempts made against their dashboard. As an added benefit it would also allow for other services such as Fail2ban to act on failed authentication attempts.

While this feature can partly be achived already using Nginx’s Basic HTTP authentication, I see no reason it should not be native to Homarr as it can only ever add to user security.

Priority

Low (Nice-to-have)

[Stylback]

Would just logging auth attempts in console be enough ? We don’t really log anything.

I know services like Gotify lets Docker handle the logging, it’s then still possible to “export” the logs using the entrypoint option. A docker compose file then has the following added to it:

entrypoint: sh -c "/app/gotify-app 2>&1 | tee /app/data/gotify.log"

So as long as it’s possible to somehow access the logs and write it to your own file, like with the entrypoint example above, there should be no need for a fully-blown log system.

I am not a Docker developer, so I can’t help further with how that would look like.

[ajnart]

These logs should show up when using docker logs and be exploited later. The changes will be added in the next patch if you confirm the format is what you were looking for.

I took a look at the commit and it seems to have all that anyone needs to act upon a failed authentication; date+time, warning message and a request origin. I am satsified!

Edit: From a security standpoint, I suggest removing the ${tried} variable as anyone inspecting said logs could then guess the correct password if you were to make a typo.

Ok I understand your comment on the pr better @manuel-rw . I’ll fix it