Passwort-Management am ESP32: WiFiManager sicher einsetzen

Passwort-Management am ESP32 ist einer der am häufigsten unterschätzten Faktoren, wenn aus einem Bastelprojekt ein dauerhaft betriebenes IoT-Gerät wird. Spätestens dann, wenn ein ESP32 in mehreren Haushalten, in einer Ferienwohnung oder in einer Werkstatt eingesetzt wird, stellt sich die Frage: Wie gelangen WLAN-Zugangsdaten sicher auf das Gerät – ohne sie hart in den Code zu schreiben, ohne sie offen über Serial-Monitor auszugeben und ohne unbeabsichtigt ein dauerhaftes Einfallstor zu schaffen? Genau hier kommt WiFiManager ins Spiel: Die Bibliothek ermöglicht ein komfortables Provisioning über einen temporären Access Point und ein Captive Portal. Komfort allein reicht jedoch nicht aus. Dieser Praxisleitfaden zeigt Ihnen, wie Sie WiFiManager sicher einsetzen, welche Konfigurationen essenziell sind, wie Sie Passwörter in der Flash-Struktur des ESP32 verantwortungsvoll behandeln und welche Alternativen sich lohnen, wenn Sie höhere Sicherheitsanforderungen haben. Ziel ist eine robuste Lösung, die Einsteiger umsetzen können, aber gleichzeitig Best Practices erfüllt, die auch im professionellen Umfeld zählen.

Warum WLAN-Passwörter am ESP32 besonders schützenswert sind

WLAN-Zugangsdaten sind nicht nur ein Schlüssel zum Internet, sondern häufig ein Schlüssel zum gesamten Heimnetz. Wer das WLAN-Passwort kennt oder aus einem Gerät extrahieren kann, erhält potenziell Zugriff auf lokale Dienste, Smart-Home-Zentralen, Netzwerkspeicher und andere IoT-Geräte. Beim ESP32 kommt hinzu: Viele Projekte werden lange betrieben, selten aktualisiert und stehen oft in Reichweite (z. B. im Außenbereich, im Treppenhaus, im Keller). Ein gutes Passwort-Management reduziert nicht nur das Risiko von Missbrauch, sondern auch Folgeschäden wie Datenabfluss, Manipulation von Sensorwerten oder die Übernahme von Aktoren (Licht, Türöffner, Relais).

• Physischer Zugriff ist realistisch: Ein ESP32 kann entwendet oder kurzzeitig an einen Rechner angeschlossen werden.
• Funk ist abhörbar: Offene Provisioning-APs oder unverschlüsselte Konfigurationsseiten sind besonders riskant.
• „Nur im Heimnetz“ ist kein Schutz: Viele Angriffe passieren innerhalb des LAN (z. B. kompromittierte Clients).
• Langzeitbetrieb braucht Wartbarkeit: Zugangsdaten ändern sich; Geräte müssen sicher neu provisioniert werden können.

Was WiFiManager macht – und wo die typischen Risiken liegen

WiFiManager ist in der Arduino-Welt beliebt, weil es die Inbetriebnahme stark vereinfacht: Der ESP32 startet bei fehlender WLAN-Verbindung einen eigenen Access Point (AP), stellt eine Weboberfläche bereit und lässt den Nutzer die Ziel-SSID samt Passwort eintragen. Danach verbindet sich das Gerät mit dem gewünschten WLAN und speichert die Daten lokal, sodass der Vorgang nicht bei jedem Neustart wiederholt werden muss.

Die Risiken entstehen meist nicht durch die Bibliothek selbst, sondern durch unsichere Standard- oder „Bequemlichkeits“-Einstellungen:

• Offener Provisioning-AP: Wenn der Konfigurations-AP kein Passwort hat, kann jeder in Reichweite beitreten.
• Zu lange AP-Laufzeit: Ein dauerhaft aktiver AP erhöht die Angriffsfläche erheblich.
• Unzureichende Portal-Absicherung: Unauthentifizierte Konfigurationsseiten oder schwache Portal-Passwörter sind problematisch.
• Preisgabe in Logs: Serial-Ausgaben oder Debug-Logs können SSIDs, Passwörter oder Tokens enthalten.
• Speicherung im Klartext: Ohne zusätzliche Maßnahmen liegen Credentials im Flash und sind bei physischem Zugriff potenziell auslesbar.

Bedrohungsmodell: Gegen wen wollen Sie sich schützen?

Bevor Sie Einstellungen festlegen, lohnt sich eine kurze Einordnung. Sicherheit ist immer kontextabhängig. Ein Gerät im Labor hat andere Anforderungen als ein Sensor im Vorgarten.

• Gelegenheitsangreifer in Funkreichweite: Jemand sieht den AP, verbindet sich und versucht, die Konfiguration zu ändern.
• Mitnutzer/„Besucher“: Personen mit temporärem Zugriff sollen nicht dauerhaft Administrationsrechte erhalten.
• Kompromittierter Client im Heimnetz: Ein infizierter PC im LAN scannt offene Ports und versucht Geräte zu übernehmen.
• Physischer Zugriff: Gerät wird entwendet, über USB ausgelesen oder Debug-Schnittstellen werden genutzt.

WiFiManager kann in vielen Szenarien sicher betrieben werden – wenn Sie die folgenden Schutzmechanismen konsequent umsetzen.

Sicheres Provisioning: Der Konfigurations-AP darf nie „offen“ sein

Die wichtigste Regel: Der WiFiManager-Access-Point braucht immer eine WPA2-Absicherung mit einem ausreichend starken Passwort. Ein offener AP ist im Alltag der häufigste Grund, warum ein eigentlich harmloses Projekt zum Sicherheitsproblem wird. Verwenden Sie ein einzigartiges, projektspezifisches AP-Passwort und vermeiden Sie Standardwerte wie „12345678“ oder „password“.

• Starkes AP-Passwort: Mindestens 12–16 Zeichen, gemischt aus Buchstaben/Zahlen, keine Wörterbuchwörter.
• Einmaligkeit: AP-Passwort nicht für mehrere Geräte wiederverwenden.
• Keine sensiblen Namen: AP-SSID nicht „Haus_Musterstraße“ nennen; besser neutral oder mit Geräte-ID.
• Begrenzte Reichweite: Sendeleistung reduzieren, wenn das Setup in kurzer Distanz erfolgt.

AP nur bei Bedarf: Timeouts, Fail-Counter und Setup-Modus

Ein sicherer WiFiManager-Betrieb bedeutet: Der AP läuft nur dann, wenn er wirklich gebraucht wird. Ideal ist ein „Setup-Modus“, der bewusst ausgelöst wird (z. B. durch Tastendruck beim Booten) oder nur bei wiederholtem Verbindungsfehler nach einer definierten Zeit aktiv wird.

• Timeout für Captive Portal: Nach z. B. 2–5 Minuten automatisch beenden, wenn keine Konfiguration erfolgt.
• Fail-Counter: AP erst nach mehreren gescheiterten WLAN-Verbindungsversuchen aktivieren, nicht sofort.
• Manueller Setup-Trigger: Ein physischer Taster (oder eine definierte GPIO-Brücke) als Voraussetzung für Provisioning.
• Kein „Dauer-AP“ als Fallback: Wenn das WLAN ausfällt, sollte das Gerät kontrolliert degradieren (z. B. lokale Funktion weiterführen), statt dauerhaft einen AP zu öffnen.

Konfigurationsportal absichern: Zugriff begrenzen und Missbrauch verhindern

Auch wenn der AP per WPA2 gesichert ist, sollten Sie davon ausgehen, dass jemand das AP-Passwort irgendwann erfährt (z. B. durch Weitergabe im Haushalt). Deshalb ist eine zweite Schutzschicht sinnvoll: das Portal selbst. Ziel ist, dass nicht jeder, der dem AP beitreten kann, automatisch kritische Einstellungen ändern darf.

• Admin-Passwort für das Portal: Schützen Sie sensible Seiten (Reset, WLAN-Wechsel, erweiterte Parameter) mit Authentifizierung.
• Minimale Oberfläche: Nur die Felder anzeigen, die nötig sind (SSID/Passwort). Keine Debug-Infos im Browser.
• Rate-Limiting im Kopf: Vermeiden Sie Features, die bruteforcefreundlich sind (z. B. unlimitierte Login-Versuche).
• Keine Offenlegung von Netzdetails: Ein AP-Portal sollte nicht automatisch Listen aller gefundenen WLANs samt RSSI im Klartext speichern oder weiterreichen, wenn es nicht erforderlich ist.

Passwörter nicht im Serial-Monitor leaken: Logging-Disziplin

Viele ESP32-Projekte sind während der Entwicklung sehr „gesprächig“. Im Produktivbetrieb ist das riskant. Ein serieller Log kann in Sekunden abgegriffen werden, wenn ein Gerät zugänglich ist. Noch kritischer: Manche Entwickler drucken versehentlich die vollständige Konfiguration oder JSON-Dumps aus.

• Keine Klartext-Credentials loggen: Weder WLAN-Passwort noch API-Keys oder Tokens.
• Release-Loglevel senken: Debug-Ausgaben deaktivieren oder auf minimale Statusmeldungen reduzieren.
• Maskieren statt ausgeben: Wenn Sie zwingend anzeigen müssen, dann nur teilweise (z. B. „****“).
• Serielle Schnittstelle abschirmen: Bei Geräten im Feld: Gehäuse, keine frei zugänglichen Pins.

Speicherung von WLAN-Credentials: Was im ESP32 wirklich passiert

Im Arduino-Umfeld nutzt der ESP32 typischerweise interne Speichermechanismen, um WLAN-Zugangsdaten zu persistieren. Das ist praktisch, aber nicht automatisch „verschlüsselt“. Wer physischen Zugriff hat und den Flash auslesen kann, hat unter Umständen die Möglichkeit, sensible Daten zu extrahieren. Deshalb sollten Sie, je nach Schutzbedarf, zusätzliche Funktionen der Plattform nutzen.

NVS und Preferences: Komfortabel, aber nicht automatisch vertraulich

Viele Projekte speichern zusätzliche Parameter (MQTT-Server, Benutzer, Tokens) in NVS (Non-Volatile Storage) über „Preferences“. Das ist für Konfigurationen sinnvoll, aber behandeln Sie alles, was Zugriff auf Netzwerke oder Dienste ermöglicht, als geheim.

• Credentials minimieren: Speichern Sie nur, was das Gerät benötigt.
• Tokens statt Passwörter: Wo möglich, nutzen Sie zeitlich begrenzte oder widerrufbare Tokens.
• Trennung von Rollen: Ein MQTT-Benutzer pro Gerät, kein globales Admin-Konto im Flash.

NVS-Verschlüsselung und Flash-Verschlüsselung: Der robuste Weg

Wenn Ihr Bedrohungsmodell physischen Zugriff einschließt, sind NVS-Verschlüsselung und Flash Encryption zentrale Bausteine. Sie sorgen dafür, dass gespeicherte Daten im Flash nicht einfach im Klartext vorliegen. Das ist besonders relevant, wenn Geräte außerhalb eines geschützten Innenraums betrieben werden.

• NVS Encryption: Verschlüsselt Inhalte des NVS, sodass Konfigurationswerte bei Flash-Dump nicht lesbar sind.
• Flash Encryption: Verschlüsselt den Flash-Inhalt auf Hardware-Ebene (Schutz gegen Offline-Auslesen).
• Secure Boot: Stellt sicher, dass nur signierte Firmware startet (Schutz gegen Manipulation/Backdoors).

Konfiguration „sicher neu aufsetzen“: Reset ohne Datenrest

Ein häufiges Praxisproblem: Ein Gerät wird verkauft, weitergegeben oder umgezogen. Dann dürfen alte WLAN-Zugangsdaten nicht auf dem ESP32 verbleiben. Ein „Factory Reset“ sollte daher konsequent sowohl WLAN-Credentials als auch zusätzliche Parameter löschen – und zwar so, dass das Gerät nicht in einem unsicheren Zustand zurückbleibt.

• Expliziter Reset-Mechanismus: Nur durch langen Tastendruck oder eine klar definierte Aktion auslösbar.
• Gezieltes Löschen: WLAN-Credentials plus alle NVS/Preferences-Einträge, die Zugangsdaten enthalten.
• Sicherer Default nach Reset: Nach dem Reset nur in den Setup-Modus wechseln, wenn der Nutzer physisch vor Ort ist.
• Kein Reset über offene Web-Endpunkte: Kritische Aktionen nicht ohne Authentifizierung im LAN anbieten.

„Evil Twin“ und Captive-Portal-Fallen: Was Sie realistisch absichern können

Beim Provisioning über WLAN existiert ein grundsätzliches Risiko: Ein Angreifer kann versuchen, ein ähnliches Netzwerk oder ein ähnliches Portal bereitzustellen (Evil Twin), um Nutzer zur Eingabe von Passwörtern zu verleiten. In vielen Heimprojekten ist das Risiko gering, aber in Mehrparteienhäusern oder öffentlichen Bereichen steigt es.

• AP-SSID eindeutig gestalten: Mit Geräte-ID oder QR-Code am Gehäuse, damit Nutzer das richtige Gerät erkennen.
• Setup nur kurz aktiv: Je kürzer das Zeitfenster, desto kleiner die Angriffsfläche.
• Portal-Passwort als zweite Hürde: Selbst wenn jemand dem AP beitritt, verhindert Portal-Auth den sofortigen Missbrauch.
• Provisioning-Alternativen prüfen: In höheren Sicherheitsklassen ist BLE/Wi-Fi Provisioning oft besser kontrollierbar.

Alternativen zu WiFiManager: Wenn Sie mehr Kontrolle brauchen

WiFiManager ist für viele Projekte ausreichend, aber nicht in jedem Szenario die beste Wahl. Wenn Sie eine professionellere Provisioning-Strecke benötigen, lohnt sich der Blick auf Alternativen, die stärker in die Plattform integriert sind oder andere Transportwege nutzen.

• Espressif Wi-Fi Provisioning (SoftAP/BLE): Unterstützt strukturierte Provisioning-Flows, häufig mit besserer Kontrolle über Security-Mechanismen.
• WPS vermeiden: WPS ist aus Sicherheitsgründen in vielen Umgebungen unerwünscht.
• Vorprovisionierte Geräteprofile: Bei Seriengeräten: WLAN-Credentials nicht verteilen, sondern Geräte in ein eigenes IoT-WLAN aufnehmen und zentral managen.
• Setup per Kabel/Serial in geschützter Umgebung: Für sehr sensible Installationen kann ein initiales Provisioning „offline“ sinnvoll sein.

Praxis-Checkliste: WiFiManager sicher einsetzen

• Provisioning-AP immer mit WPA2-Passwort: Kein offenes Setup-Netz, niemals.
• AP-SSID neutral und eindeutig: Keine Adressen, Namen oder Standortdaten; lieber Geräte-ID.
• Captive-Portal mit Timeout: Nach wenigen Minuten automatisch deaktivieren.
• Setup-Modus nur bewusst auslösbar: Taster/GPIO oder klarer Fail-Counter.
• Portal-Authentifizierung für kritische Aktionen: Reset, erweiterte Parameter, Diagnosen.
• Keine Klartext-Logs: Passwörter, Tokens und Konfiguration nicht auf Serial ausgeben.
• Credentials sparsam speichern: Nur notwendige Daten, pro Gerät getrennte Accounts.
• Bei erhöhtem Risiko: Verschlüsselung aktivieren: NVS Encryption/Flash Encryption + Secure Boot (ESP-IDF-orientiert).
• Reset sauber implementieren: Daten entfernen, aber nicht in einen dauerhaft unsicheren Zustand fallen.

Outbound-Links zu relevanten Informationsquellen

• WiFiManager (GitHub): Projektseite, Features und Konfigurationsoptionen
• Espressif Flash Encryption: Schutz vor dem Auslesen von Flash-Inhalten
• Espressif Secure Boot V2: Signierte Firmware und Schutz vor Manipulation
• NVS (Non-Volatile Storage): Technische Grundlagen zur Speicherung von Konfigurationsdaten
• Wi-Fi Provisioning (ESP-IDF): Alternative Provisioning-Ansätze über SoftAP/BLE
• OWASP IoT Project: Überblick zu typischen IoT-Risiken und Schutzmaßnahmen
• Arduino-ESP32 Core (GitHub): Plattformdetails und Implementationshintergründe

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.