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

Add a Warning in UI if the web admin password is not set #12828

Closed

Conversation

ascillato
Copy link
Contributor

@ascillato ascillato commented Aug 5, 2021

Description:

Add a Warning in Tasmota User Interface if the web admin password is not set.

To set the web admin password, you can go to CONFIGURATIONS -> CONFIG OTHER -> Web Admin Password.
Or
In the console by webpassword command.

Then, after restart, your browser will ask for Username and Password. By default the username is admin. The username can be changed by using the key WEB_USERNAME in the user_config_override.h file.

As the password is for securing the HTTP API and the web interface, this warning is not published by MQTT nor Serial. Only in the web UI.

This continues the PR: #12827

image

Related issue (if applicable): #6767

Checklist:

  • The pull request is done against the latest development branch
  • Only relevant files were touched
  • Only one feature/fix was added per PR and the code change compiles without warnings
  • The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
  • The code change is tested and works with Tasmota core ESP32 V.1.0.7.3
  • I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

@arendst
Copy link
Owner

arendst commented Aug 6, 2021

I know there are people jumping on the security bandwagon and want to add passwords to every item on the internet. I hate security. It has always been a showstopper for me. I liked tasmota for being as open as possible and watched over the years with some dismay hidden passwords being introduced.

I don't like this PR as it now even forces me to use a web password on my own local intranet. I don't use MQTT passwords and don't want to use webpage passwords either.

As it stands I won't merge this. There must be a better way for resellers to force their users to use a password without bothering me.

NOTE: Perhaps:

  • you can add a SetOption for users/resellers that want to release this enabled,
  • or have this enable only on new installations
  • and having the option of not providing a password.

@arendst arendst added the on hold by dev team Result - Feature request put on hold by member of development team label Aug 6, 2021
@ascillato
Copy link
Contributor Author

ascillato commented Aug 6, 2021

Yes, I agree. Let's find a better way for this. I did this PR following the advices in #6767.

@ascillato ascillato closed this Aug 6, 2021
@bananenfisch
Copy link

bananenfisch commented Aug 13, 2021

I don't like this PR as it now even forces me to use a web password on my own local intranet.

Is it local with this API implementation? :-D
If you think, its local (and safe), just visit my website: https://www.bananenfisch.net/fun.php

I don't use MQTT passwords and don't want to use webpage passwords either.

I dont use MQTT passwords too, because i have only trusted devices in my LAN. But: sometimes i visit untrusted websites from a browser inside my LAN - thats the bridge, which could open my garage door or modify all firmware on every tasmota device in my LAN.

Well, i've setup my passwords for the Web-API, but most users out there never heard about this issue. And the issue is public. Please print the warning (maybe with a "dismiss" button, whatever). It's really an ugly bug... if my next mate, never heard about cross-site attacks, using Tasmota without web-password, i could simple send him a link and take control over his whole house!

* or have this enable only on new installations
* and having the option of not providing a password.

Yes, please! ;-)
Tasmota get more and more users - this issue is going to be a huge problem if some attackers are smelling blood!

arendst added a commit that referenced this pull request Aug 15, 2021
@arendst
Copy link
Owner

arendst commented Aug 15, 2021

Retry with latest change. It won't tackle every attack but I think the basic functionality as demonstrated by your fun.php is disabled by default.

In fact all HTTP requests not coming from the device are disabled this way.

If users want to use HTTP web commands they have to enable SetOption128 1 and additionally set an admin password.

Let me know what you think.

EDIT1: Bugger. This fails initial setup. I will revert the change and do further testing.

arendst added a commit that referenced this pull request Aug 15, 2021
…fault blocking HTTP web commands (#12828)"

This reverts commit 996aaf2.
arendst added a commit that referenced this pull request Aug 15, 2021
Add command ``SetOption128 1`` disabling web referer check default blocking HTTP web commands (#12828)
@arendst
Copy link
Owner

arendst commented Aug 15, 2021

Another try. See above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold by dev team Result - Feature request put on hold by member of development team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants