RFC: Not enabling WebREPL by default on boot in 1.8.6

[pfalcon]

When we initially planned ESP8266 Kickstarter campaign, we of course wanted to provide nice out-of-the box experience, like you take a board, power it ... and connect to it and run WebREPL. Even when we decided that to get going further with the campaign, it makes sense to make it software-only, we decided to keep that "out of the box" approach. Even though in this case, a user would need to install a flasher application, plug the board to USB port, run flasher, etc., and then it's just one extra small step to the serial REPL. Well, I'm glad we went to implement it and show how cool it is. There was always a caveat however: if we make a networked setup easy for first-time users, that inevitably leads to security concerns - if you can set up a device easy, some bad guy can get hold of it easily to - and possibly, before you.

The situation aggravated since we started to provide firmware publicly to everyone - while it perhaps a reasonable expectation that campaign backers followed provided information closely enough to understand security implications, a random passer by who decided to give it a try may have no idea that s/he *must* to configure WebREPL password ASAP.

So, in such situation, it's just irresponsible to keep WebREPL enabled by default. Instead, what's being proposed is that WebREPL daemon is not enabled by default. Instead, a setup script (e.g. "import webrepl_setup") is provided, which, when run over standard serial REPL, will ask user if they want to enable WebREPL and ask to set individual password.

It's perhaps too short a notice to make this change in the upcoming 1.8.5 release, so I'd plan to do it for 1.8.6.

If you have any opinions, suggestions, or concerns, feel free to share them here.

UPDATE: The change is fully implemented, see updated docs:

The documentation changes for the original change being discussed (1st message of the thread) went live:

• http://docs.micropython.org/en/latest/e ... ive-prompt
• http://docs.micropython.org/en/latest/e ... -over-wifi

[chrisgp]

That seems pretty reasonable to me. I'm been planning to add authentication support to a telnet server I wrote and I was going to use the same credentials set for the WebREPL. Something you might consider is keeping the setup script slightly generic, maybe "import service_setup" instead of tying it specifically to the WebREPL, and framing the setup in such a way that the WebREPL might just be one of multiple services the user could turn on and off in the future.

I can understand wanting to keep it super simple though.

[deshipu]

The whole setting a password through webrepl on first connect was weird and awkward anyways. The way webrepl saves the password in a file is strange too. But why do you need a separate module again?

Why not change the webrepl.start() to *require* a password as a parameter, and then have webrepl.setup(password) that would simply add a line with webrepl.start() to the end of boot.py?

[kfricke]

If you have any opinions, suggestions, or concerns, feel free to share them here.

Why is the password forced down to ASCII charset? With thepassword stored in plaintext this is a source of problems.
Why not store a salted SHA256 hash (better use the ESP MAC address for the salt than nothing)?

[pfalcon]

Something you might consider is keeping the setup script slightly generic, maybe "import service_setup" instead of tying it specifically to the WebREPL, and framing the setup in such a way that the WebREPL might just be one of multiple services the user could turn on and off in the future.

Thanks. We have a very specific aim - supporting WebREPL well (including securely), and that's one of a hundred aims we have regarding the ESP8266 port work. At this time, we cannot take another, 101th aim. But we encourage community (e.g. you) to explore these possibilities.

[pfalcon]

Why ...

I'd kindly ask to keep this thread on the original topic - pros, cons and how-to-do-it-well's of disabling WebREPL start by default. If you have any other bugreports or topics to discuss regarding WebREPL, please use appropriate means to report/raise (a bug ticket; separate thread).

Why not store a salted SHA256 hash (better use the ESP MAC address for the salt than nothing)?

... But many questions can be answered if you just know that MicroPython's design is governed by desire to avoid obscure and esoteric solutions where they can be avoided. Can you do SHA256 in your mind? That already should provide a good answer why password isn't stored as a salted SHA256 hash. Are you sure that doing like it is being done has big drawbacks and doing it another way has huge benefits? Open a separate thread and argue it. Just a useful suggestion - as a first stage of considering your idea, be your own skeptic and critic.

[kfricke]

Constructive feedback is always welcome!

[markxr]

I honestly think that enabling webrepl (even without any suggestion of a password) is not a problem.

Micropython is not intended as an end-user product; access will only ever be viable for those in limited wifi range. And anyone who flashes their ESP board with Micropython, we can reasonably expect to be a developer.

While we can't expect the developer to consider the security implications fully, enabling a nice out-of-box experience is probably important too.

Because the device can't connect to a normal accesspoint immediately, there's probably no danger of them being used in a DDoS attack, etc, because they have no upstream connectivity.

So what's an attacker going to do? Yes they could write a program which breaks your ESP module** , there's $2 down the drain, get over it.

Mark

** As I have done on several occasions; the esp8266 is unbrickable, but the flash is very brickable.

[deshipu]

So what's an attacker going to do? Yes they could write a program which breaks your ESP module** , there's $2 down the drain, get over it.

That depends entirely on what is connected to it. There are for instance those sonoff modules, for controlling any normal, high-voltage appliances. Or you can have an artistic installation controlled with esp8266 that, say, moves your sculpture and is deployed in public.

Also note, that you will have this problem not just when flashing your freshly unpacked esp8266 module at home, but also every time when you upgrade the micropython firmware on it, when it requires complete flash erase.

[deshipu]

@kfricke I think that an option to specify the password as a hash, instead of plaintext, is a great idea for an advanced feature (as long as it doesn't grow the firmware too much, so that that 20kB database code that nobody uses can still fit there), but you also have to remember that just using unsalted hash is not very helpful in increasing the security. Since the salt would also need to be stored somewhere on the device, you didn't really secure it that much. Sure, now it takes 10 minutes to get the password instead of 10 seconds, but it's still there.