Web UI does not accept wifi password with * #5231
Comments
|
I think * is used by the webui to mask the current password and to detect if a change is needed when the save button is clicked so until that is changed it will not accept * Issue #5010 seems to be related where @ascillato mentions that the characters referenced in that issue is not supported by the core... it is marked as a duplicate issue so my guess is if you search the issues you will find what the outcome was but I know that this is not the first time this issue is raised. |
|
Tasmota used to be happy with "*" in the password, and now people are saying it is "not supported"? This needs to be resolved. "Not supporting ''" has turned into a disaster for me ... yesterday, I OTA flashed a plug, set the wifi password - which in my network starts with '' and has ever since wifi arrived on this planet ... `00:02:20 WIF: Connecting to AP1 ROGERS in mode 11N as sonoff-3959... 00:02:37 WIF: Connect failed with AP timeout 00:02:37 WIF: Connecting to AP1 ROGERS in mode 11N as sonoff-3959... 00:02:54 WIF: Connect failed with AP timeout` So, first, it is a bug that "*" is not supported - the UI needs to be sorted out. Second (and I will raise a bug for this), it is a bug that Tasmota does not initiate the configuration AP when it cannot connect to the network. |
|
Sorry, it is not supported. Some special characters are not supported for password. Sorry if this is not what you want, but are deliberately not supported. |
|
Previous versions of Tasmota were happy with "*" in the password - and now it does not work. This makes it a bug, or the limitation should be noted in very large characters IMHO. When, and why, was the decision made to deliberately remove support for reasonable characters? What API is not working? The Arduino API accepts the characters - if I enter the password via the serial debug, the password is used correctly. |
|
It is a design decision from the project owner. |
|
Since the password ofuscation for the webmenu was inserted in version 5.10 the * was not supported. Sorry. This is a known limitation. If you look in issues you will find the original issue. |
|
Closing issue as it is duplicated and as this is a known limitation that was already marked to be worked on later. |
|
The people on TV use ******** as their passwords... you can see them type it sometimes :) |
|
:-)
I’m looking at the code - it looks like I can fix this quicker than changing my passwords ...
For some reason both placeholder and value is set in the html for the page. In reality only placeholder should be set - and then the test for “string contains *” can be removed ...
Sent from my phone ...
… On 15 Feb 2019, at 13:21, Andre Thomas ***@***.***> wrote:
The people on TV use ******** as their passwords... you can see them type it sometimes :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
You actually don't need the *** to be displayed and submitted when the password is not changing. If its length is 0 then just ignore it and keep the original password - if it has something in it then update it accordingly. This was the original proposal from @ascillato - just nobody gotten around to it yet. There are some issues with the ESP8266 core though relating to special characters... I can't remember all of them though. |
|
Ok - I’ll put the fix together and then spend a long time working out how to make a pull request ;-)
Sent from my phone ...
… On 15 Feb 2019, at 13:59, Andre Thomas ***@***.***> wrote:
You actually don't need the *** to be displayed and submitted when the password is not changing. If its length is 0 then just ignore it and keep the original password - if it has something in it then update it accordingly. This was the original proposal from @ascillato - just nobody gotten around to it yet.
There are some issues with the ESP8266 core though relating to special characters... I can't remember all of them though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Great! Remember:
|
|
Just for reference, this issue is duplicated from #3654 |
|
That all makes sense.
The issue is how we distinguish between an empty field meaning “blank password” or “User did not enter anything”. I shall consult to work out what best practice is - hopefully this does not mean a pile of javascript ... Certainly the current method of ignoring passwords containing “*” is not good as it is obscure and not a normally a problem.
Can you point me to anything regarding the ESP core and “Not allowed” characters?
Sent from my phone ...
… On 15 Feb 2019, at 14:08, Adrian Scillato ***@***.***> wrote:
Great!
Remember:
the password should not be sent to the webpage because it can be seen with a password viewer for Chrome
the user should be able to use a blank password (yes, some people use that)
the user should be able to modify its password
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
The newer core (2.5.0) supports now some special characters. If you search in issues in arduino repository you will find it. But the issue is if you use an old core like 2.3.0 that does not supports some special characters. As some users are using 2.3.0, those characters also needs to be discarded, so passwords containing those, should be rejected. They produce software watchdogs. Please, check in issues of arduino esp8266 core. Thanks. |
|
Understood. Meanwhile, I have 2 ideas for simple fixes which should improve matters:
Thoughts? Should I fix this throughout xdrv_01_webserver.ino and make a pull request ? We then could add a specific note to the wiki to say that this one password is ignored ? Alternatively, we say that passwords must be 8 characters or more - and then we can accept "blank" passwords for open wifi networks. The alternative to this fix would be to put some fairly tricky javascript together - and this would be overkill for what is a tricky problem. In fairness, we should look at a wholly different approach if this is the case. |
|
@spock64 check what @ascillato said - its unlikely that a PR for this will be merged to Sonoff-Tasmota development because we plan to continue support for 2.3.0 core. As a matter of fact, earlier communication between myself and @arendst is indicative that I will even be pushing 2.3.0 based development binaries. The reason for continued support for the 2.3.0 core is because some wifi setup's are not happy with the 2.4.2 or 2.5.0 implementation. |
|
So, I get the idea that there are issues with 2.3.0 core. My proposal does not make things worse for anyone using this version - things would be as good or bad as they are now. What I am proposing to fix is the needless Tasmota-imposed limitation around passwords containing the asterisk - right now any password is accepted by the code, provided it does not contain an asterisk. I understand that there are problems with the Arduino libraries and special characters no doubt due to html header processing issues - but the current Tasmota implementation does not do anything about these problems. It simply adopts a rather simplistic algorithm that "If password contains "*", it's bad, if not it's good". My proposal is that zero length passwords are used to mean "", other passwords of less than 8 characters are ignored and overwritten by the default or the existing password. Passwords of 8 characters or more are saved for use. Why would a simple PR like this not be accepted when it improves the product without any new side effects? |
|
If you write it properly you could possibly make it core independent I guess. |
|
The current code is core-independent - all the action is in xdrv_01_webserver.ino. I'm proposing to change ...
to ... This would be done both for both passwords. This change would refuse passwords that matched D_ASTERIX. We could instead have ...
This change would allow zero length passwords or passwords of 8 or more characters. Passwords from 1 to 7 characters in length would be ignored. Either of my suggestions is an improvement on the arbitrary filtering of the asterisk. BTW, I know that asterisks in passwords are not a problem in 2.3.0 because I have hardware using Tasmota pre 5.10 that are working with my asterisk-laden password. What do you think? |
|
It is only important what the project owner thinks. |
|
@spock64 A good place to start would be to test the change on all the cores and make sure it does not have any impact. Then you can add that information to your PR for the owner to decide if he wants to merge it or not. |
|
Remember that the solution need to be fool proof (I didn't make a typo there), so if someone had a password like abcd1234 and he/she wanted to change to abcd1235, may be he/she will just delete the last * and add a 5 thinking it is going to work, ending in a incorrect password:*******5 Also, it has to be a backwards compatible solution. So it should accept passwords of any lenght (if someone do an upgrade and his/her password is no longer supported, when trying to change it will have also issues) So, there are several conditions that needs to be met for a proper password check routine. By now, you are realizing that it will not be a super simple fix just to accept the *. Also, at this moment I don't recall exactly but we need to verify, if you use a * as part of a password in core 2.3.0, it don't work (it is a core issue, not Tasmota if I recall correctly) . If you use in latest core 2.5.0 I know it works. That I think was the decision of not allowing * in the password. Anyway, I agree with you that this password routine needs an enhancement but it is not super simple that. I think it can be achieved but with a major rewrite and meeting several conditions as the ones stated before. Anyway, if you want to work on that, you have our support, but all those conditions have to be met. |
|
Disclosure: I am computer scientist with over 40 years of experience. I know how to handle password entry screens. I also know what is practical to implement and what is not. For most of that time I have run professional software teams, and have been an engineering director and / or a CTO for more than half that time. Let’s just say that I have an idea of what I am talking about.
Your total requirements, taken as a whole, are unreasonable in the context of an embedded device - the UI needs to be simple and predictable (which is why I am willing to engineer a solution to the arbitrary “no * in password rule). They far exceed that which any normal “full fat” website or system implements, let alone what a good quality embedded project should. Let me explain why ...
First, some facts to shape what we need to do. IEEE 802.11 specifies that SSIDs are 32 octets. Passwords for WPA2 secured networks need to be between 8 and 63 octets. Remember that octets are 8-bit numbers - not characters.
Reasonable implementations of user interfaces to provide these parameters place limits on what can actually be input. The current implementation ignores the minimum length requirements, and uses a NULL password field when the network referenced by the SSID had no password. It also arbitrarily filters passwords containing the asterisk -
Let’s analyze what we can do ...
Looking at the standard, when entering an SSID, we should ensure that the resulting vector of octets is of length less than or equal to 32. The current implementation does not enforce this 32 octet limit. I would propose to implement this. The standard allows for any character to be valid - but there is some experience to suggest that errors in the parsing libraries in the Arduino Core means that we should reject SSIDs that contain problematic characters. The current implementation does not limit the length nor validate the entered SSIDs. In fact there is a buffer overrun problem IRRC.
We can assume that anyone entering a zero-length password is doing so because they are joining an unencrypted (insecure) network.
In the real world, no-one would realistically deploy IOT technology on an unencrypted or insecure network. No-one would or should deploy a WPA network as they are insecure and essentially equivalent to an unencrypted network. Please note that in many jurisdictions, deploying an insecure Wi-Fi network can be a breach of the law.
So, given that everyone is using WAP2, we can verify that the passwords entered meet the minimum requirements. This means ensuring that a password is of length equal to or greater than 8 octets. Passwords from 1 to 7 octets are invalid. We should again enforce a maximum length for passwords - 63 octets for WPA2.
When presenting an input field for a password, we should use the html password field, but being html there are practical limits as to what can be done in our context. What looks reasonable is to set the input field to look as though it contains a value - we could do this with a placeholder value or even an invalid value. It’s also reasonable to set the maximum length input too - although a check should still be made in the receiving code.
Let’s imagine what would happen if the password field contained “**” (using the value field attribute) ...
* If the user does not change the field, we know readily that this is the case as the “**” would be returned in the html. We would not update the password in this case
* If the user simply deleted the “**” leaving an empty field, we would know as a zero length string is returned in the html.
* For any other input that the user makes, we can treat that as a password and try to do something sensible. First if its less then 8 characters long, we know it is invalid and need to do something about it - the current implementation simply substitutes the last stored password value (which may well be a default value). We could also remove characters that we deem to be invalid - but this would need to be core dependent and we would need to have a definitive list of such characters and be able to document them.
* If a user wishes to change one character of a password, they need to re-input the whole password. I know of no system allowing a single character to be changed with the remainder of the password obscured - and this is for very good reasons. I therefore would not propose to implement this functionality.
Now, the current implementation silently replaces input fields with existing or default data when a field is deemed invalid - for example, a perfectly valid password containing a “*” is silently replaced by whatever the previous (or default) password is. It is very poor practice to silently replace input like this, in my option. To resolve this problem, we would need to redesign how the input dialogues work and add functionality to show when the system is rejecting input. This would be quite significant work and I do not propose to implement this.
An alternative approach is to have simple rules for input fields and ensure that only minimal, reasonable and necessary restrictions are imposed. These rules can be clearly documented (they are not at the moment).
In summary, I propose to make a PR which includes the following:
* SSIDs limited to 32 octets
* Filtering of SSIDs that contain certain characters - provided I can find out what the issues are
* Passwords of zero or 8 to 63 octets length
* Filtering of passwords that contain certain a characters - again provided I can find out what the issues are.
* Documentation for the wiki that makes these rules clear
That’s a lengthy post, but shows that we can make a improvement in the quality of the product with a few small, simple changes.
[Edited to show maximum length of WPA2 passwords is 63 octets]
… On 15 Feb 2019, at 21:35, Adrian Scillato ***@***.***> wrote:
@spock64
Remember that the solution need to be fool proof (I didn't make a typo there), so if someone had a password like abcd1234 and he/she wanted to change to abcd1235, may be he/she will just delete the last * and add a 5 thinking it is going to work, ending in a incorrect password:*******5
Also, it has to be a backwards compatible solution. So it should accept passwords of any lenght (if someone do an upgrade and his/her password is no longer supported, when trying to change it will have also issues)
So, there are several conditions that needs to be met for a proper password check routine.
By now, you are realizing that it will not be a super simple fix just to accept the *.
Also, at this moment I don't recall exactly but we need to verify, if you use a * as part of a password in core 2.3.0, it don't work (it is a core issue, not Tasmota if I recall correctly) . If you use in latest core 2.5.0 I know it works.
That I think was the decision of not allowing * in the password.
Anyway, I agree with you that this password routine needs an enhancement but it is not super simple that. I think it can be achieved but with a major rewrite and meeting several conditions as the ones stated before.
Anyway, if you want to work on that, you have our support, but all those conditions have to be met.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
how can you argument the logic of spock :) you have my thumbs up, but would you care showing me the good reasons for not letting me update my obscured password (i.e uppercase the third character). As a user I always hated this. |
|
The main reason is that most people (people who don’t use github!) would make more errors in password entry “editing” the password like this. While it’s a bit more inconvenient to re-enter the whole password, it ends up being simple to understand for the user and straightforward to code securely (this is important as it’s a password after all). It’s also quite tricky to look for the 23rd character in a line of blobs or asterisks and edit just that one - at least with my eyes it is!
There’s a whole bunch of research going back decades on how to do password entry, validation and verification properly. It does not seem sensible to me to implement something that goes against that and break new ground in a small embedded software project!
TBH I agree that, from a personal viewpoint, I would like to “edit” passwords like this, but accept that it’s not a good thing to do :-)
Sent from my phone ...
… On 16 Feb 2019, at 08:06, joba-1 ***@***.***> wrote:
how can you argument the logic of spock :) you have my thumbs up, but would you care showing me the good reasons for not letting me update my obscured password (i.e uppercase the third character). As a user I always hated this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@spock64 thx for the elaborate information. Tasmota is all about as much functionality in a tight space. |
|
@arendst Thx for making your view clear. And also for this great project! Would you be happy with a PR that removes the filtering of the asterisk? As you say, it’s up to the router to know whether it’s ok or not. |
|
@spock64 pls do. |
andrethomas2
added
enhancement
|
Fix merged to development with #5242 |
andrethomas2
added
bug
|
Just a note to myself for further testings. I have just read that some other firmwares that also uses Arduino Esp8266 core are having issues with wifi passwords containing the following characters. :"+$%{;*!"/\ Will test later to find out the exactly unsupported list. |
|
Can you point me to them? If so, I can take a look tomorrow and work out what is going on. There’s a few places that these characters can become troublesome!
… On 17 Feb 2019, at 18:36, Adrian Scillato ***@***.***> wrote:
Just a note to myself for further testings.
I have just read that some other firmwares that also uses Arduino Esp8266 core are having issues with wifi passwords containing the following characters.
:"+$%{;*!"/\
Will test later to find out the exactly unsupported list.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#5231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AViF0-p5TtR9l6oo3UogGnp4urhnB0VKks5vOaFDgaJpZM4a88VG>.
|
wifi passwd can't used *
examples: Auik987222*
The text was updated successfully, but these errors were encountered: