passwords beeing transmitted unencrypted

[dadosch]

When you enter the passwords into the config site (wifi, influx, basic auth Password), they will be transmitted unencrypted or if BASICAuth already enabled, base64 encoded. A attacker could - when the esp8266 is in config ap mode - (decode the BASICAuth user and password) and get the home wifi psk and then attack also the users's home WiFi network.

[ricki-z]

This is a known problem. You could look at the code and give us a hint how to solve this ;-) There is a function in the aktual code that should mask the passwords. But there seems to be an error in this function. After saving an unchanged config the masked (and with that wrong) password ist saved.

[dadosch]

As far as I read the code, the user gets only asterix for his password (*********) when he opens the config page.
Wenn der User aber ein neues Passwort eingibt, wird das dann nicht auch im Klartext übertragen?
Die einfachste Lösung IMHO wäre (zumindest im AP-Modus), den access point mit einem Passkey zu versehen, welches beim ersten Start generiert wird und dann (bei jedem Start) über die serielle Konsole ausgegeben wird. (Das Smartphone des Eigentümers speichert ja normalerweise den Passkey)

Ist der ESP8266 dann mit einem verschlüsselten Heim-WLAN verbunden, ist es ja kein großes Problem, das Passwort unverschlüsselt zu übertragen (machen ja viele Router auch).

Wenn der ESP8266 aber mit einem offenen, unverschlüsselten WLAN (z.B. Freifunk) verbunden ist, kann mMn HTTPS die Config-Seite ab besten "abdichten", was allerdings noch nicht in den Arduino-Core gemerged wurde.

esp8266/Arduino#3001
https://github.com/earlephilhower/Arduino/blob/master/libraries/ESP8266WebServer/examples/HelloServerSecure/HelloServerSecure.ino

[ricki-z]

Bei einem offenen, unverschlüsselten Netz sollte ein bekanntes Passwort (falls überhaupt vorhanden) kein Problem sein. Fürs Heim-WLAN lässt sich mit einem maskierten Passwort zumindest nichts mehr durch bloßen Abruf der Seite auslesen. Bleibt also als Lücke nur noch das versendete Passwort (wenn das Passwort neu eingetragen wurde, sonst werden ja die Sternchen gesendet).
Leider scheint aber noch ein Bug in dem Teil des Sourcecodes zu sein. Laut mehrerer Nutzer wurde in der Version NRZ-2017-095 beim Speichern das Sternchenpasswort in die Konfiguration geschrieben. Deswegen habe ich das in der aktuell ausgelieferten Firmware zunächst wieder deaktiviert.
Wir würden gern https nutzen, da geht es dann aber neben der fehlenden Unterstützung im Arduino-Core schon mit dem Problem der selbst signierten Zertifikate weiter. Da bringen die meisten Browser inzwischen eine für Durchschnittsnutzer echt abschreckende Fehlermeldung.
Die serielle Konsole für die Ausgabe eines Passcodes zu nutzen ist auch keine wirkliche Lösung. Die wenigsten Nutzer bekommen das hin, da was auszulesen.

[pathmapper]

Problem der selbst signierten Zertifikate weiter. Da bringen die meisten Browser inzwischen eine für Durchschnittsnutzer echt abschreckende Fehlermeldung.

What about using https by default (if it could be implemented), document the browser error in the wiki and on http://luftdaten.info/feinstaubsensor-bauen/, explain why it is related to a self signed certificate and show how to handle it?

[ricki-z]

The mentioned secure ESP8266Webserver will work with a predefined private key and certificate. With auto update these would be identical for all sensors. So we would need to implement key generation and cert signing. This will need too much RAM and flash. Thats why we can't implement HTTPS.
Are this enough reasons to end the discussion about a HTTPS server interface on the esp8266? You can also look at the various threads in the esp8266 forum.

[pathmapper]

I was only thinking about:

Da bringen die meisten Browser inzwischen eine für Durchschnittsnutzer echt abschreckende Fehlermeldung.

Because of

This will need too much RAM and flash. Thats why we can't implement HTTPS.

it really makes no sense to think further about HTTPS.

Thanks for the explanation!

[ricki-z]

@dadosch the actual firmware version should be masked in the form fields. So the only moment the password is transmitted unencrypted is the moment of saving the password. As we can't implement https (too few RAM) I think we need to live with that for the moment.
I will think about the idea of a passcode and how to implement this in a way that most users can handle.

[dadosch]

OK, I will close this for now.

[Adorfer]

in case somebody is courious, take a look at
https://arduino.stackexchange.com/questions/25344/how-to-implement-simple-quick-hmac-on-arduino

And off course, it takes some Flash and Ram.