nielsonm236
commented
4 months ago This turns out to be a much more complex problem than expected, with the complicating factors being: a) Handling multiple logins on a per host basis b) Handling login timeouts on a per host basis c) Handling multiple Browsers on a single host d) Handling multiple attempts to log in with the wrong password, lockout and lockout timing e) Handling login function cancelation f) Handling "forgot my password" resolution g) ... and more ... As a result the code kept growing and at this point it only fits in the Browser Only Upgradeable version of code. Seems to work well in that one case. I'm going to release it for that build only, but now that I have working code I might be able to reduce the size and get it to fit as an option somewhere else.
I've had another request for a Login page. I've resisted this in the past because: 1) It simply won't fit unless there is an I2C EEPROM, and even then it might not fit depending on the requirements. 2) I don't see any way to make it truly secure in an Internet environment as there is not enough code space or horsepower to support SSL or https. There might be tricks to make a Login page "guess resistant", but no way to make it hacker resistant. 3) I still think that if someone needs hacker resistance they need to expose these devices ONLY on their internal network, then use a pc or server as a gateway for Internet access. There are lots of methods and programs out there to give you a secure connection to a computer on your network, then you can use that computer to access the Network Modules. But alas, this seems too complicated for some.
Still, I will look into it again. At this point I'm collecting more information from the requester as follows: a) Tell me more about the purpose of having ID and Password is ... hacker security? Or just limiting casual access to the device? b) This feature will require addition of the I2C EEPROM. c) Should there be a "try three times then lock out for an hour" kind of protection?