Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional protection for web interface (access control) #75

Closed
dergigi opened this issue Feb 9, 2022 · 4 comments · Fixed by #102
Closed

Additional protection for web interface (access control) #75

dergigi opened this issue Feb 9, 2022 · 4 comments · Fixed by #102
Assignees
Labels
enhancement New feature or request security Issues related to security; could lead to loss of funds

Comments

@dergigi
Copy link
Contributor

dergigi commented Feb 9, 2022

Issue raised by Mr. Kukks and briefly discussed in Call 8.

The Web UI endpoint might be exposed publicly, e.g. via Umbrel, since everything that runs on Umbrel might be exposed and accessible via <public-ip> - so anyone might go to <public-ip>/joinmarket and access the interface.

By default, all wallets are password protected and locked, so this might not be as critical as one might think at first, but some access control might be good in any case. See RTL, Thunderhub, et. al. They all have the same problem and solve it in a similar way.


This Umbrel announcement might be relevant: https://community.getumbrel.com/t/umbrel-0-4-8-is-out-with-cryptographically-secure-default-app-passwords/4696

@dergigi dergigi added enhancement New feature or request security Issues related to security; could lead to loss of funds labels Feb 9, 2022
@dergigi
Copy link
Contributor Author

dergigi commented Feb 9, 2022

I'm not sure how critical this is, i.e. if we should implement this for v0.0.3 or move it to the next version.

On the one hand, every wallet is protected by a password, but on the other hand, that password is set by the user and might be really bad and easily brute-forced.

Thoughts @dnlggr @theborakompanioni @dennisreimann?

@theborakompanioni
Copy link
Collaborator

theborakompanioni commented Feb 9, 2022

I'm not sure how critical this is, i.e. if we should implement this for v0.0.3 or move it to the next version.

On the one hand, every wallet is protected by a password, but on the other hand, that password is set by the user and might be really bad and easily brute-forced.

Since we are proxying requests and therefore exposing the server api, we have a responsibility here.

In umbrel we can make use of $APP_PASSWORD

Unique plain text password that can be used for authentication in your app, shown to the user in the Umbrel UI

As far as I understand, most of the work for this has to be done in the runtime environment (e.g. web server - nginx in our case), but we need at least a mode in the ui (e.g. with a build flag) where we ask for a password on the very first screen (before loading the wallets) and include it in every request.. did I understand that correctly?

However.. can we use a .htpasswd in the first iteration as "cheap" placeholder for something more sophisticated?

@theborakompanioni theborakompanioni self-assigned this Feb 10, 2022
@theborakompanioni
Copy link
Collaborator

However.. can we use a .htpasswd in the first iteration as "cheap" placeholder for something more sophisticated?

See joinmarket-webui/jam-docker#12
Basic Authentication is used in the initial version.

@theborakompanioni
Copy link
Collaborator

ghcr.io/joinmarket-webui/joinmarket-webui-dev-standalone has been uploaded and is used in #99. 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request security Issues related to security; could lead to loss of funds
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants