WLAN-Passwörter im Code verstecken: Best Practices für Maker

WLAN-Passwörter im Code verstecken ist ein Klassiker unter Maker-Projekten: Ein ESP8266 verbindet sich mit dem Heimnetz, MQTT läuft, Sensoren senden Daten – und irgendwo im Sketch steht das Klartext-Passwort. Spätestens wenn der Code auf GitHub landet, im Forum geteilt wird oder Sie ihn an Freunde weitergeben, ist das Risiko real: Ein einziges unbedachtes Commit kann Zugangsdaten dauerhaft kompromittieren. Gleichzeitig ist „Verstecken“ ein missverständlicher Begriff: In der Praxis geht es weniger um magische Verschleierung, sondern um sauberes Secret-Management, klare Trennung zwischen Quellcode und Konfiguration, sowie sichere Prozesse rund um Build, Versionsverwaltung und Gerätebetrieb. Denn selbst wenn Sie Passwörter nicht in den Sketch schreiben, können sie über Log-Ausgaben, Konfigurationsportale oder schlecht gesicherte Backups abfließen. Dieser Leitfaden zeigt bewährte Best Practices für Maker – von schnellen, alltagstauglichen Lösungen für Einsteiger bis zu professionelleren Ansätzen mit Build-Variablen, Secret-Dateien und Netzwerksegmentierung. Ziel ist ein Workflow, bei dem Sie Projekte bedenkenlos teilen können, ohne jedes Mal hektisch zu prüfen, ob irgendwo noch ein WLAN-Key, API-Token oder MQTT-Passwort versteckt ist.

Warum Klartext-Passwörter im Sketch so gefährlich sind

Viele Maker unterschätzen zwei Dinge: Erstens bleiben veröffentlichte Daten oft für immer auffindbar. Selbst wenn Sie ein Passwort später aus einem Repository entfernen, kann es in alten Commits, Forks oder Caches weiter existieren. Zweitens ist ein WLAN-Passwort kein „kleiner Schaden“. In Heimnetzen hängt daran meist deutlich mehr: Smart-Home-Zentrale, NAS, Drucker, Kameras oder sogar Arbeitsgeräte. Ein kompromittiertes WLAN ist häufig der erste Schritt, um sich im Netzwerk umzusehen.

• Leichtes Versehen: Ein Screenshot, ein Code-Snippet oder ein „kurz mal hochladen“ reicht.
• Commit-Historie: Git speichert Vergangenheit; Löschen ist nicht gleich „weg“.
• Wiederverwendung: Viele nutzen dasselbe Passwort an mehreren Stellen (WLAN, Router, Dienste).
• Seiteneffekte: Logs, Crashdumps und Konfigurationen können Secrets ebenfalls enthalten.

Grundprinzip: Code und Secrets strikt trennen

Die wichtigste Regel lautet: Quellcode ist öffentlichkeitsfähig, Secrets nicht. Alles, was ein Angreifer zum Zugang braucht, gehört nicht in Dateien, die routinemäßig versioniert, geteilt oder in Backups gespiegelt werden. Stattdessen halten Sie Zugangsdaten in einer separaten, nicht getrackten Konfiguration oder in Build-Variablen. So bleiben Projekte reproduzierbar, ohne dass Sie Passwörter verteilen.

• Code: Logik, Sensorhandling, Netzwerkroutinen, Protokolle.
• Konfiguration: SSID, WLAN-Passwort, MQTT-Credentials, API-Keys, Hostnames.
• Gerätespezifisches: pro Gerät eigene Namen/Keys statt „ein Passwort für alle“.

„Verstecken“ ist nicht gleich „Sichern“

Ein häufiges Missverständnis: Obfuskation (z. B. Base64, XOR, „komische Zeichenketten“) schützt nicht ernsthaft. Wer Zugriff auf Firmware, Flash oder seriellen Output hat, kann solche „Tricks“ meist leicht zurückrechnen. Echte Sicherheit entsteht durch Prozesse: getrennte Dateien, Zugriffskontrolle, minimale Rechte, sichere Übertragung und regelmäßige Rotation.

Best Practice für Arduino IDE: Separate Secret-Datei nutzen

Für klassische Arduino-Workflows ist eine separate Datei die einfachste Lösung. Sie legen eine lokale Datei an (z. B. secrets.h), die Zugangsdaten enthält und von der Versionsverwaltung ausgeschlossen wird. Im Hauptprojekt binden Sie diese Datei ein und verwenden nur Platzhalter oder Variablennamen. So können Sie den Sketch teilen, ohne Ihre Secrets zu veröffentlichen.

• Vorteil: schnell, verständlich, funktioniert ohne zusätzliche Tools.
• Nachteil: Secrets liegen weiterhin im Klartext auf dem Entwicklungsrechner.
• Wichtig: Die Datei muss zuverlässig in .gitignore stehen.

Template-Datei für Teamwork

Wenn mehrere Personen am Projekt arbeiten, ist ein Template sinnvoll: Sie committen z. B. secrets.example.h mit Dummy-Werten. Jeder kopiert es lokal zu secrets.h und trägt seine eigenen Daten ein. Das reduziert Fehler und beschleunigt Onboarding.

PlatformIO: Build-Variablen und Umgebungsdateien

Wer PlatformIO nutzt, kann Secrets sauberer über Umgebungsvariablen oder separate Konfigurationsdateien einbinden. PlatformIO unterstützt flexible Build-Flags, die zur Buildzeit Werte setzen, ohne sie in den Code zu schreiben. Auch hier gilt: Der Trick ist nicht „Verschleierung“, sondern Trennung und Prozesskontrolle.

• Build-Flags: Werte werden zur Buildzeit injiziert, nicht im Code gespeichert.
• Environment-spezifisch: unterschiedliche WLANs für Entwicklung/Produktion.
• Saubere Repo-Struktur: Konfigurationsdateien mit Secrets bleiben lokal.

Wenn Sie sich tiefer einlesen möchten: PlatformIO Dokumentation bietet einen guten Überblick zu Umgebungen und Build-Konfiguration.

ESPHome: Secrets-Management „out of the box“

Für viele Smart-Home-Maker ist ESPHome besonders praktisch, weil es ein standardisiertes Secrets-Konzept mitbringt. Sie definieren Zugangsdaten in einer separaten Secrets-Datei und referenzieren sie in den Geräte-Konfigurationen. Das macht Projekte sehr teilbar, ohne dass SSID und Passwörter im Klartext in jeder Gerätekonfiguration stehen.

• Einheitlicher Workflow: Secrets zentral pflegen, Geräte referenzieren.
• Skalierbar: viele Sensoren/Nodes mit konsistenter Struktur.
• Wartung: einfacher Wechsel von Passwörtern ohne Code-Anpassungen.

Ein Einstieg ist über ESPHome möglich.

Wenn Sie Code teilen: Git-Hygiene und „Secret-Leaks“ vermeiden

Die meisten Leaks passieren nicht durch „Hacker“, sondern durch Routinefehler. Deshalb sind Git-Regeln und Checks so wertvoll. Definieren Sie früh, welche Dateien nie ins Repo gehören, und automatisieren Sie möglichst die Prüfung, bevor etwas gepusht wird.

• .gitignore: Secret-Dateien, lokale Konfigurationen, Backups ausschließen.
• Pre-Commit-Checks: einfache Regeln, die typische Muster blocken (z. B. „password=“).
• Code-Review: vor dem Teilen einmal gezielt nach SSID/Keys suchen.
• Kein Copy-Paste: Screenshots/Forum-Posts sind genauso riskant wie Repos.

Für allgemeine Best Practices zur sicheren Softwareentwicklung sind die OWASP Cheat Sheet Series eine verlässliche, herstellerunabhängige Quelle.

Was tun, wenn es schon passiert ist?

Wenn ein WLAN-Passwort oder Token öffentlich geworden ist, hilft „löschen“ allein selten. Die sichere Reaktion ist Rotation: Passwort ändern, betroffene Geräte neu verbinden, ggf. weitere Accounts prüfen. Bei Git-Repositories kann eine Historienbereinigung notwendig sein, aber die wichtigste Maßnahme bleibt das Ändern der kompromittierten Secrets.

Auf dem Gerät: Captive Portal vs. Hardcoding

Viele Maker nutzen Captive Portals (Konfigurations-WLAN), um SSID und Passwort beim ersten Start einzutragen. Das kann sinnvoll sein, hat aber Sicherheitsrisiken: Wenn das Portal offen bleibt oder schwach abgesichert ist, kann es zur Hintertür werden. Captive Portal ist dann gut, wenn es zeitlich begrenzt ist und nur nach physischem Trigger aktiv wird (z. B. Tastendruck beim Boot).

• Setup nur bei Bedarf: Standardbetrieb ohne Konfigurations-Access-Point.
• Kurzes Zeitfenster: z. B. 5–10 Minuten, dann automatisch deaktivieren.
• Starkes Setup-Passwort: auch für den temporären AP.
• Keine sensiblen Logs: SSID/Passwort nicht im Serial Monitor ausgeben.

Gerätesicherheit ist mehr als WLAN

Selbst wenn Sie WLAN-Passwörter sauber handhaben, können andere Secrets kritisch sein: MQTT-Passwörter, API-Tokens, OTA-Passwörter oder Web-UI-Logins. Behandeln Sie alles, was Zugriff ermöglicht, mit derselben Disziplin.

Netzwerkstrategie: IoT-WLAN und Rechtebegrenzung

Eine sehr wirksame Best Practice ist, IoT-Geräte in ein separates Netz zu setzen (z. B. eigene SSID oder VLAN). Dann ist selbst ein kompromittiertes Gerät nicht automatisch der Schlüssel zum gesamten Heimnetz. Zusätzlich können Sie Firewall-Regeln setzen: Der ESP8266 darf nur den MQTT-Broker erreichen, aber nicht NAS oder PCs.

• Separates IoT-Netz: reduziert Seitwärtsbewegungen bei Kompromittierung.
• Minimaler Zugriff: nur die Dienste erlauben, die wirklich benötigt werden.
• Keine eingehenden Verbindungen: IoT-Geräte nicht aus anderen Netzen direkt ansprechbar machen.
• Fernzugriff via VPN: statt Portfreigaben oder „offene“ Web-UIs.

Für IoT-Risiken und Gegenmaßnahmen ist das OWASP IoT Project ein guter Orientierungsrahmen.

MQTT und Credentials: Pro Gerät eigene Identität statt „ein Login für alles“

Viele Maker-Projekte nutzen MQTT, weil es leichtgewichtig und Smart-Home-kompatibel ist. Genau deshalb sollten MQTT-Zugangsdaten besonders sauber verwaltet werden. Ein gemeinsamer MQTT-User für alle Geräte ist bequem, aber riskant: Wenn ein Gerät kompromittiert ist, sind alle Topics offen. Besser ist: pro Gerät ein eigener Benutzer und eine ACL, die nur die nötigen Topics erlaubt.

• Pro Gerät eigener User: reduziert Blast Radius.
• ACLs: Publish/Subscribe strikt begrenzen.
• TLS wo möglich: schützt Credentials vor Mitlesen im LAN.
• Status-Topics: Firmware-Version, Uptime und Fehlerzähler helfen beim Monitoring.

Grundlagen zu MQTT: MQTT.org. Für Mosquitto-Konfiguration (Auth/ACL/TLS): Mosquitto Dokumentation.

Obfuskation: Was sie bringt und wo sie trügt

Manche Maker fragen: „Kann ich das Passwort nicht einfach verschlüsseln?“ Im Hobbykontext wird dann häufig eine harte Wahrheit sichtbar: Wenn der Schlüssel zum Entschlüsseln ebenfalls auf dem Gerät liegt, ist die Verschlüsselung eher eine Hürde gegen Zufallsblicke als gegen echte Angriffe. Das kann für bestimmte Szenarien trotzdem sinnvoll sein (z. B. um versehentliche Leaks in Logs zu reduzieren), sollte aber nicht als primäre Sicherheitsmaßnahme verstanden werden.

• Pro: erschwert triviales Auslesen im Klartext, reduziert „Copy-Paste-Leaks“.
• Contra: schützt nicht bei Gerätezugriff, Firmware-Dump oder Debug-Analyse.
• Praxis: Trennung, Zugriffskontrolle, Rotation und Netzwerksegmentierung sind wichtiger.

Minimalziel für Maker

Wenn Sie eine einfache, realistische Sicherheitsstufe wollen: Secrets nicht committen, IoT-Netz trennen, pro Gerät eigene Credentials, Konfigurationsmodus nur temporär, und keine offenen Dienste im Router.

OTA-Updates und Secrets: Wie Sie Passwortwechsel ohne Chaos schaffen

Passwörter sollten rotierbar sein. Das klingt „enterprise“, ist aber im Maker-Alltag wichtig: Wenn Sie irgendwo ein Leak vermuten oder Gästen Zugang gegeben haben, möchten Sie das IoT-WLAN oder MQTT-Passwort ändern können, ohne jedes Gerät per Kabel neu flashen zu müssen. OTA-Updates helfen, aber nur, wenn OTA selbst sicher ist (Authentifizierung, kein offenes OTA im Netz). Außerdem ist es hilfreich, wenn Geräte mehrere WLAN-Profile oder einen Fallback-Mechanismus unterstützen, damit ein Passwortwechsel nicht zu „offline für immer“ führt.

• OTA absichern: starkes OTA-Passwort und begrenzter Zugriff im Netzwerk.
• WLAN-Rotation planen: Geräte nacheinander umstellen, nicht alle gleichzeitig „abschießen“.
• Fähigkeit zur Neukonfiguration: sicherer Wartungsmodus statt dauerhaftes Portal.
• Inventar führen: Geräte-IDs und Versionen dokumentieren, damit nichts vergessen wird.

Praktische Checkliste: Best Practices für WLAN-Passwörter im Maker-Alltag

• Keine Secrets im Repo: Zugangsdaten in separater, ignorierter Datei oder Build-Variablen.
• Template-Datei: Beispiel-Konfiguration ohne echte Werte für einfaches Teilen.
• Pro Gerät eigene Credentials: MQTT-User, Tokens, Hostnames individuell.
• IoT-Netz trennen: separate SSID/VLAN, minimale Firewall-Regeln.
• Setup nur temporär: Konfigurationsportal nur nach physischem Trigger und Zeitlimit.
• Keine sensiblen Logs: SSID/Passwörter/Tokens niemals in Serial/HTTP ausgeben.
• Rotation ermöglichen: OTA-Strategie und Prozess für Passwortwechsel definieren.
• Vor dem Teilen prüfen: Suchlauf nach „ssid“, „password“, „token“, „apikey“, „mqtt“.

Outbound-Links zu relevanten Informationsquellen

• OWASP Cheat Sheet Series (sichere Muster für Secrets, Auth und Web)
• OWASP IoT Project (Risiken und Best Practices für IoT-Systeme)
• PlatformIO Dokumentation (Build-Konfiguration und Umgebungen)
• ESPHome (Secrets-Management und Geräteverwaltung)
• MQTT.org (Protok erklärt und Best Practices)
• Mosquitto Dokumentation (Authentifizierung, ACLs und TLS)

Häufige Fragen aus der Maker-Praxis

Reicht es, das WLAN-Passwort zu „kodieren“ (z. B. Base64)?

Nein, das ist keine echte Sicherheit. Base64 ist keine Verschlüsselung, sondern eine Darstellung. Es verhindert höchstens, dass ein Passwort sofort ins Auge fällt. Für reale Sicherheit brauchen Sie Trennung von Code und Secrets, Zugriffskontrolle und ein sauberes Netzwerk-Setup.

Was ist der schnellste sichere Einstieg ohne viel Tooling?

Eine lokale Secret-Datei, die konsequent in .gitignore ausgeschlossen wird, plus ein Beispiel-Template im Repo. Ergänzen Sie das mit einem getrennten IoT-WLAN und deaktivieren Sie offene Setup-Portale im Dauerbetrieb.

Ich teile Code nur privat – muss ich trotzdem aufpassen?

Ja. Private Chats, E-Mail-Anhänge oder Cloud-Ordner werden schnell weitergeleitet, gesichert oder falsch einsortiert. Außerdem bleiben Passwörter oft lange unverändert. Eine einmal saubere Struktur erspart Ihnen dauernde Bauchschmerzen.

Wie kann ich Secrets rotieren, ohne Geräte neu flashen zu müssen?

Planen Sie OTA-Updates und einen sicheren Wartungsmodus ein. Ideal ist, wenn Geräte nach Passwortänderung vorübergehend in einen sicheren Konfigurationsmodus wechseln können, ohne dauerhaft ein offenes Portal zu betreiben.

Was ist die wichtigste „fortgeschrittene“ Maßnahme?

Netzwerksegmentierung plus minimale Rechte: Ein eigenes IoT-Netz und pro Gerät eingeschränkte MQTT-Rechte reduzieren den Schaden massiv, selbst wenn ein einzelnes Gerät kompromittiert wird.

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.