dgtlmoon
[feature] Password enforced by default
In certain scenarios it could be useful to don't have a password, for example when you're not exposing the docker container to the network (even private network), but only to localhost. That's the only reasonable scenario when it could be okay to don't have a password-protected instance (even in private networks it's a problem).
Something like this could be implemented:
Option 1
- On first install generates a random uuid and use that as a one-time use path for a setting password page. e.g.
http://localhost:8000/3da194fb-8363-48c2-a210-9f3eafc10533. - How to provide to the user this URL? I don't know, printing the URL in the terminal could be a problem (if they use
-din docker-compose up). - The page presents the option to set a password or to don't use a password (with a banner saying "You have to know you are doing a stupid thing").
- Once the decision is made, the URL becomes invalid and that page is not accessible anymore. The password options are then only editable in the settings.
I know security by obscurity is not something useful, but in my opinion a uuid v4 for this scenario could be okay.
I know you provide an hosted version of changedetection too, so I don't know if this is a problematic process and how this can be adapted to the hosted version.
Option 2
Another option could be to create a file with a temporary pseudo-random password. That one is valid just for the first use, when you login you're prompted with a page giving the user 2 options:
- change the password
- don't use a password (with the same banner saying "You have to know you are doing a stupid thing")
Finally that file is deleted and the one-time password invalidated.
I was thinking, when the app is first run/setup, it can ask you, or you can 'skip'
I was thinking that a password is needed 100% because of baseline security. But in reality there are some cases where a password could be avoided, like a local setup not exposed on public internet (still a stupid choice if you ask me from a security pov). So I'd say that this option "when the app is first run/setup, it can ask you, or you can 'skip'" it could be okay. In my opinion there must be a red banner highlighting the fact that a strong password is definitely a good choice.
Was just looking if there was an option for an initial password when deploying the container. I think it would be nice if it was set as an env variable like DEFAULT_PASSWORD=. If it was empty nothing would change from current behavior, but if it was set use it and expect the user to change it later or not.
@JoaoSangue the initial password must be a random password different for every installation. If the password is always the same, anyone can know that and it's like having no password
@edoardottt, as you stated in the issue, not having a password could be useful for a local deploy that wouldn't be exposed on the internet, that's why I suggested for it to be optional. Regarding the env I mentioned, I could have suggested a better name, but was thinking it could follow something similar to what some database images do like postgres and mariadb. This way it wouldn't be necessary to generate a random key, as the person deploying would already be able to set it's preferred password, and this way it wouldn't be the same known password for every installation.
@JoaoSangue sorry if I wasn't clear. What I mean is that in my opinion is better to have a random password different for every instance created at installation/ first deploy time and then if the user doesn't want a password, the user can change the password env var to an empty value. I prefer this way instead of the opposite: having a blank password and if the user wants to set it, set a password in the password env var. The first method eliminates the problem of an installation left without password security due to forgetfulness or whatsoever. If an instance is without a secure password it's because the user explicitly wanted an unsecured instance.