-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
Security: Allow user-specified or randomly generated password #57
Comments
You can increase the security by generating the password from the chip ID of the Arduino. The password will be unique and can't be used anywhere else only on this Arduino ( and swapping the ESP doesn't change anything here ). So it's fairly robust as the user has a) to have something: access to the Arduino and b) the password which should be known only to the user. The question is how to tell the user the password ( and thats the case for any solution ) The only way i can see today is the serial console ( to maintain the need of having the physical device ) the first time the Arduino boots 5 and it should not show up in the AP SSID name of course ) |
A user specified password can be done only either at compile time baked into the code or through the <+> command and store it as i understand it so far. |
Aha! Yes let's use the ID of the ATMEGA. I don't know how I didn't think of that, I've written several routines now to grab that on several chips. Probably should have the Arduino show the password up until there's some kind of acknowledgment that the password was seen. Like a serial terminal will ask if they have seen the password and wait for acknowledgment before storing the response in EEPROM and booting. |
If we go for the ESP32 as the base MCU we can do far better things as we can use cryptography and have access to bcrypt so we can store the password in encrypted format and nobody can reverse engineer it using the right Algorithm. on thing i can see as well that at first startup ( at bit like for WiFi ) the user gets asked for a password which then gets stored ( not safe as we can't actually encrypt it but better than nothing ). |
And in addition, we can throw an ATECC608A crypto chip at the problem for certificates and whatever. ESP32-WROOM32-SE has a built in chip and there's libraries for using it in the IDF (not yet in the Arduino stuff) |
Sheesh... so we need an AP password that cant be easily guessed but throwing crypto security at this is batshit crazy On 22 Nov 2020 22:16, Dave Cutting <[email protected]> wrote:
And in addition, we can throw an ATECC608A crypto chip at the problem for certificates and whatever. ESP32-WROOM32-SE has a built in chip and there's libraries for using it in the IDF (not yet in the Arduino stuff)
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
This needs more thought. From the thread so far, this seems to "techy" of a solution and is very user-unfriendly. Keep this really simple for the end-user. This is the reason at work why engineers don't design UIs. That is for a UI design team. :-) I see 4 define statements. #define ENABLE_WIFI (true or false) Nice and simple. If CLIENT, then SSID and PASSWORD is your home network. If AP, then SSID and PASSWORD are what to broadcast and connect to. |
test build action
Currently the password for AP mode is generated from the SSID name, which is a security risk. There needs to be a way for the user to define an AP mode password.
Discussion so far included using a random number generator to generate a random number that is then stored in EEPROM and used for all subsequent bootups. The problem with this is that the random number generator is a pseudo-random number denerator, and would have to be initialized (seeded) with something like an analogRead() function or a number generated from the outgoing 1's and 0's of the DCC waveform interrupt.
Currently, the method for changing the AP password is to
#define DONT_TOUCH_WIFI_CONFIG
and then config the WiFi with the<+>
command. Maybe that's good enough.The text was updated successfully, but these errors were encountered: