Die MQTT-Authentifizierung mit Benutzername und Passwort ist der am weitesten verbreitete Weg, auf dem ein Client seine Identität gegenüber einem Broker nachweist, und zugleich der am häufigsten falsch konfigurierte. In diesem Leitfaden sehen Sie genau, wie Zugangsdaten im CONNECT-Paket übertragen werden, warum sie nur innerhalb von TLS sicher sind, welche Reason Codes Sie bei falschen Angaben erhalten und wie Sie pro Gerät einen eigenen Satz Zugangsdaten verwalten.
Wie Zugangsdaten im CONNECT-Paket übertragen werden
Jede MQTT-Session beginnt mit einem CONNECT-Paket des Clients. Sein variabler Header enthält Connect-Flags, darunter das User Name Flag und das Password Flag. Sind diese Flags gesetzt, enthält die Payload direkt nach der Client-ID und der optionalen Will Message den Benutzernamen als UTF-8-Zeichenkette und das Passwort als Binärdaten.
CONNECT
Protocol name: MQTT
Protocol level: 5 (MQTT 5.0) or 4 (MQTT 3.1.1)
Connect flags: username=1, password=1, clean start=1
Keep alive: 60
Payload:
Client ID: sensor-0042
Username: YOUR_USERNAME
Password: YOUR_PASSWORD <- raw bytes, not hashed
In der MQTT-Schicht gibt es kein Hashing, kein Challenge-Response und keine Verschlüsselung. Das Passwort wird unverändert gesendet. Wer den TCP-Strom auf Port 1883 mitlesen kann, liest das Passwort mit einem Paketmitschnitt-Tool in Sekunden aus.
Einige Protokolldetails sind wissenswert:
- In MQTT 3.1.1 darf ein Passwort nur gesendet werden, wenn auch ein Benutzername gesendet wird. MQTT 5.0 hat das gelockert, sodass ein Passwort allein gesendet werden kann, die meisten Broker erwarten aber weiterhin beides.
- Das Passwortfeld ist binär und kann daher beliebige Bytes enthalten, auch Tokens. So nutzen tokenbasierte Verfahren wie die MQTT-JWT-Authentifizierung dasselbe Feld.
- MQTT 5.0 definiert außerdem eine erweiterte Authentifizierung über die Property Authentication Method und AUTH-Pakete für Challenge-Response-Mechanismen. Benutzername und Passwort bleiben die gängige Basis.
Warum TLS bei Passwörtern Pflicht ist
Da das Passwort im Klartext über das Netzwerk geht, ist die MQTT-Authentifizierung mit Benutzername und Passwort ohne TLS in jedem nicht vertrauenswürdigen Netzwerk kaum besser als gar keine Authentifizierung. TLS verschlüsselt die gesamte Session einschließlich des CONNECT-Pakets und lässt den Client prüfen, dass er mit dem echten Broker spricht und nicht mit einem Betrüger, der Zugangsdaten sammelt.
| Port | Transport | Sicher für Zugangsdaten? |
|---|---|---|
| 1883 | MQTT über einfaches TCP | Nein, Passwort auf der Leitung sichtbar |
| 8883 | MQTT über TLS | Ja, mit Zertifikatsprüfung |
| 8083 | MQTT über WebSocket | Nein |
| 8084 | MQTT über sicheren WebSocket (/mqtt) |
Ja |
Verwenden Sie bei ConnectMQ immer Port 8883 für Geräte und Dienste und 8084 für Browser, sobald Sie Zugangsdaten senden. Der Broker präsentiert ein Let's-Encrypt-Zertifikat, dem die Standard-CA-Bundles von Desktop- und Server-Betriebssystemen vertrauen. Eingebettete Clients benötigen die Root-CA in der Firmware; der Leitfaden zur MQTT-TLS-Konfiguration behandelt diesen Schritt.
Prüfen Sie außerdem das Zertifikat. Wer die Prüfung deaktiviert (insecure, setInsecure(), rejectUnauthorized: false), erhält zwar Verschlüsselung gegen passives Mitlesen, aber keinen Schutz vor einem Angreifer, der die Verbindung abfängt und sein eigenes Zertifikat präsentiert.
Mit Benutzername und Passwort verbinden
Die Beispiele verwenden die Platzhalter YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID, die Sie beim Anlegen eines Brokers im Portal erhalten. Wenn Sie noch keinen eingerichtet haben, erläutert der Leitfaden zum Cloud-MQTT-Broker die Hosting-Optionen.
Python (paho-mqtt 2.x)
import os
import ssl
import paho.mqtt.client as mqtt
HOST = os.environ.get("MQTT_HOST", "YOUR_BROKER_HOST")
USERNAME = os.environ["MQTT_USERNAME"] # niemals fest in die Versionsverwaltung schreiben
PASSWORD = os.environ["MQTT_PASSWORD"]
CLIENT_ID = os.environ["MQTT_CLIENT_ID"]
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("Rejected:", reason_code) # z. B. Bad user name or password
client.disconnect()
return
print("Authenticated")
client.publish(f"devices/{CLIENT_ID}/status", "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.connect(HOST, 8883, keepalive=60)
client.loop_forever()
Kommandozeile
mosquitto_pub -h YOUR_BROKER_HOST -p 8883 \
--cafile /etc/ssl/certs/ca-certificates.crt \
-i YOUR_CLIENT_ID -u YOUR_USERNAME -P "$MQTT_PASSWORD" \
-t 'devices/YOUR_CLIENT_ID/status' -m online -V mqttv5
Lesen Sie das Passwort aus einer Umgebungsvariable, statt es auf der Kommandozeile einzutippen, wo es in der Shell-Historie und in Prozesslisten landet.
Was bei falschen Zugangsdaten passiert
Der Broker beantwortet CONNECT mit einem CONNACK. Der Code verrät, ob das Problem bei den Zugangsdaten oder bei der Autorisierung liegt:
| Situation | CONNACK in MQTT 3.1.1 | Reason Code in MQTT 5.0 |
|---|---|---|
| Akzeptiert | 0x00 | 0x00 Success |
| Client-ID abgelehnt | 0x02 Identifier rejected | 0x85 Client Identifier not valid |
| Falscher Benutzername oder falsches Passwort | 0x04 Bad user name or password | 0x86 Bad User Name or Password |
| Gültige Zugangsdaten, aber nicht erlaubt | 0x05 Not authorized | 0x87 Not authorized |
Ausführliche Schritte zur Fehlerbehebung finden Sie unter MQTT Connection Refused: Not Authorized. Zwei praktische Regeln gelten für jeden Client:
- Nicht sofort in einer engen Schleife erneut versuchen. Falsche Zugangsdaten korrigieren sich nicht von selbst, und viele Broker werten schnelle Fehlversuche als Angriff. ConnectMQ sperrt IP-Adressen nach wiederholten fehlgeschlagenen Anmeldungen, sodass sich eine falsch konfigurierte Flotte, die auf den Broker einhämmert, selbst aussperren kann.
- Verwenden Sie exponentielles Backoff mit Jitter und machen Sie Authentifizierungsfehler in Logs oder im Gerätestatus sichtbar, getrennt von Netzwerkfehlern.
Zugangsdaten pro Gerät: warum und wie
Die Abkürzung, mit der die meisten Projekte beginnen, ist ein gemeinsamer Benutzername samt Passwort, fest in jedes Gerät eingebaut. Das funktioniert am ersten Tag und macht ab dann Ärger:
- Ein einziges kompromittiertes Gerät legt die gesamte Flotte offen.
- Sie können kein einzelnes Gerät sperren, ohne alle neu zu flashen.
- Logs können Ihnen nicht sagen, welches Gerät sich fehlerhaft verhalten hat.
Zugangsdaten pro Gerät beheben alle drei Probleme. In Werken mit vielen Edge-Gateways und SPS-Anbindungen entsprechen sie zudem dem Grundsatz eindeutiger Geräteidentitäten, den auch IEC 62443 vorsieht. Auf einem selbst betriebenen Mosquitto-Broker würden Sie eine Passwortdatei pflegen:
# Datei mit dem ersten Benutzer anlegen, weitere dann ohne -c hinzufügen
mosquitto_passwd -c /etc/mosquitto/passwd sensor-0001
mosquitto_passwd /etc/mosquitto/passwd sensor-0002
# mosquitto.conf
listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
Die Datei speichert gesalzene Hashes, nicht die Passwörter selbst, und der Broker muss nach Änderungen neu geladen werden. Wer das selbst betreibt, muss außerdem das TLS-Zertifikat erneuern und die Datei über alle Instanzen synchron halten.
Zugangsdaten pro Gerät bei ConnectMQ
Bei ConnectMQ erzeugt der Broker die Zugangsdaten für Sie. Wenn Sie im Portal einen Broker anlegen, erhalten Sie Benutzername, Passwort und Client-ID, und die Client-ID ist an die ausgestellten Zugangsdaten gebunden. Diese Bindung ist wichtig: Ein gestohlenes Passwort lässt sich nicht mit einer beliebigen Client-ID verwenden, und zwei Geräte können sich nicht unbemerkt einen Satz Zugangsdaten teilen, weil sie um dieselbe gebundene Identität konkurrieren würden.
Empfohlene Praxis auf einem verwalteten MQTT-Broker:
- Stellen Sie für jedes Gerät oder jeden Dienst einen eigenen Satz Zugangsdaten aus und halten Sie fest, welches physische Gerät welche Client-ID besitzt.
- Speichern Sie das Passwort in geschütztem Speicher auf dem Gerät, nicht im Quellcode. Siehe MQTT-Zugangsdaten sicher auf Geräten speichern.
- Verbinden Sie sich nur über 8883 oder 8084 mit Zertifikatsprüfung.
- Planen Sie Änderungen ein: Der Leitfaden zur Rotation von Zugangsdaten zeigt, wie Sie Zugangsdaten in einer ganzen Flotte ohne Ausfallzeit ersetzen.
Mandanten sind voneinander isoliert, sodass die für Ihren Broker ausgestellten Zugangsdaten nur Zugriff auf den Verkehr Ihres Brokers gewähren. Kontingente und Flood-Schutz gelten pro Tarif, was den Schaden begrenzt, den ein einzelner kompromittierter Client anrichten kann.
Benutzername und Passwort im Vergleich zu anderen Methoden
| Methode | Stärke | Schwäche |
|---|---|---|
| Benutzername und Passwort über TLS | Einfach, von jeder Client-Bibliothek unterstützt | Statisches Geheimnis; muss gespeichert und rotiert werden |
| Client-Zertifikate (mTLS) | Starke Identität, kein gemeinsames Geheimnis auf der Leitung | Zertifikatslebenszyklus und PKI müssen betrieben werden |
| JWT im Passwortfeld | Kurzlebig, trägt Claims | Benötigt einen Token-Aussteller und Uhrzeitsynchronisation auf den Geräten |
Für die meisten Flotten sind eindeutige Passwörter pro Gerät über geprüftes TLS eine solide Basis. Der Leitfaden zu Best Practices für MQTT-Sicherheit behandelt die Schichten, die darauf aufbauen.
Mit ConnectMQ starten
Verzichten Sie auf Passwortdateien und Zertifikatserneuerungen. Ein verwalteter MQTT-Broker von ConnectMQ bietet Ihnen TLS auf 8883 und 8084, generierte und an Client-IDs gebundene Zugangsdaten sowie IP-Sperren bei wiederholten fehlgeschlagenen Anmeldungen. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte.
Häufig gestellte Fragen
Ist die MQTT-Authentifizierung mit Benutzername und Passwort sicher?
Für die meisten Einsätze ist sie sicher genug, wenn sie über TLS mit Zertifikatsprüfung und mit eindeutigen Passwörtern pro Gerät verwendet wird. Über einfaches TCP auf Port 1883 ist das Passwort für jeden sichtbar, der den Verkehr mitschneiden kann.
Verschlüsselt MQTT das Passwort?
Nein. MQTT sendet das Passwort als rohe Bytes im CONNECT. Verschlüsselung kommt ausschließlich von der TLS-Schicht um die Verbindung.
Kann ich mich mit Benutzername und Passwort am öffentlichen MQTT-Broker anmelden?
Der öffentliche MQTT-Broker unter broker.connectmq.com akzeptiert anonyme Verbindungen mit jeder nicht leeren, eindeutigen Client-ID und ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Für authentifizierten, privaten Verkehr erstellen Sie Ihren eigenen Broker und verwenden die generierten Zugangsdaten.
Was ist der Unterschied zwischen 0x86 und 0x87?
0x86 bedeutet, dass Benutzername oder Passwort falsch waren. 0x87 bedeutet, dass die Zugangsdaten zwar verstanden wurden, der Client aber nicht berechtigt ist, sich zu verbinden oder die Aktion auszuführen.
