L'authentification MQTT par identifiant et mot de passe est la méthode la plus répandue pour qu'un client prouve son identité à un broker, et c'est aussi la plus souvent mal configurée. Dans ce guide, vous verrez précisément comment les identifiants transitent dans le paquet CONNECT, pourquoi ils ne sont sûrs qu'à l'intérieur de TLS, quels reason codes vous obtenez lorsqu'ils sont erronés et comment gérer un jeu d'identifiants par appareil.
Comment les identifiants transitent dans le paquet CONNECT
Chaque session MQTT commence par un paquet CONNECT envoyé par le client. Son en-tête variable contient des flags de connexion, dont le User Name Flag et le Password Flag. Lorsque ces flags sont activés, le payload transporte le nom d'utilisateur sous forme de chaîne UTF-8 et le mot de passe sous forme de données binaires, juste après le client ID et l'éventuel message Will.
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 <- octets bruts, non hachés
Il n'y a ni hachage, ni challenge, ni chiffrement au niveau de la couche MQTT. Le mot de passe est envoyé tel quel. Toute personne capable de lire le flux TCP sur le port 1883 peut lire le mot de passe en quelques secondes avec un outil de capture de paquets.
Quelques détails du protocole méritent d'être connus :
- En MQTT 3.1.1, un mot de passe ne peut être envoyé que si un nom d'utilisateur l'est aussi. MQTT 5.0 a assoupli cette règle pour qu'un mot de passe puisse être envoyé seul, mais la plupart des brokers attendent toujours les deux.
- Le champ mot de passe est binaire : il peut donc contenir des octets arbitraires, y compris des jetons. C'est ainsi que des schémas à base de jetons comme l'authentification MQTT par JWT réutilisent ce même champ.
- MQTT 5.0 définit aussi une authentification étendue via une propriété Authentication Method et des paquets AUTH, pour les mécanismes de type challenge-réponse. Le couple identifiant/mot de passe reste la base commune.
Pourquoi TLS est obligatoire avec les mots de passe
Comme le mot de passe traverse le réseau en clair, l'authentification MQTT par identifiant et mot de passe sans TLS ne vaut guère mieux que l'absence d'authentification sur tout réseau non fiable. TLS chiffre toute la session, y compris le paquet CONNECT, et permet au client de vérifier qu'il dialogue avec le vrai broker et non avec un imposteur qui collecte des identifiants.
| Port | Transport | Sûr pour les identifiants ? |
|---|---|---|
| 1883 | MQTT sur TCP en clair | Non, mot de passe visible sur le réseau |
| 8883 | MQTT sur TLS | Oui, avec vérification du certificat |
| 8083 | MQTT sur WebSocket | Non |
| 8084 | MQTT sur WebSocket sécurisé (/mqtt) |
Oui |
Sur ConnectMQ, utilisez le port 8883 pour les appareils et les services, et le port 8084 pour les navigateurs, dès que vous envoyez des identifiants. Le broker présente un certificat Let's Encrypt, reconnu par les bundles d'autorités de certification standard des systèmes d'exploitation de bureau et de serveur. Les clients embarqués ont besoin que l'autorité racine soit incluse dans le firmware ; le guide de configuration TLS pour MQTT couvre cette étape.
Vérifiez aussi le certificat. Désactiver la vérification (insecure, setInsecure(), rejectUnauthorized: false) vous apporte un chiffrement contre l'écoute passive, mais aucune protection contre un attaquant qui intercepte la connexion et présente son propre certificat.
Se connecter avec un nom d'utilisateur et un mot de passe
Les exemples utilisent les valeurs génériques YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID, que vous obtenez en créant un broker dans le portail. Si vous n'en avez pas encore configuré, le guide du broker MQTT cloud passe en revue les options d'hébergement.
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"] # ne jamais coder en dur dans le gestionnaire de sources
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) # ex. 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()
Ligne de commande
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
Lisez le mot de passe depuis une variable d'environnement plutôt que de le saisir sur la ligne de commande, où il finirait dans l'historique du shell et dans la liste des processus.
Que se passe-t-il lorsque les identifiants sont erronés
Le broker répond au CONNECT par un CONNACK. Le code indique si le problème vient des identifiants ou de l'autorisation :
| Situation | CONNACK MQTT 3.1.1 | Reason code MQTT 5.0 |
|---|---|---|
| Accepté | 0x00 | 0x00 Success |
| Client ID rejeté | 0x02 Identifier rejected | 0x85 Client Identifier not valid |
| Nom d'utilisateur ou mot de passe erroné | 0x04 Bad user name or password | 0x86 Bad User Name or Password |
| Identifiants valides, mais non autorisé | 0x05 Not authorized | 0x87 Not authorized |
Les étapes de dépannage complètes se trouvent dans MQTT connection refused : not authorized. Deux règles pratiques s'appliquent à tout client :
- Ne réessayez pas immédiatement en boucle serrée. Des identifiants erronés ne se corrigeront pas d'eux-mêmes, et de nombreux brokers considèrent les échecs rapides comme une attaque. ConnectMQ bloque les adresses IP après des échecs de connexion répétés : une flotte mal configurée qui martèle le broker peut donc se bloquer elle-même.
- Utilisez un backoff exponentiel avec jitter et faites remonter les échecs d'authentification dans les journaux ou le statut de l'appareil, séparément des erreurs réseau.
Des identifiants par appareil : pourquoi et comment
Le raccourci par lequel commencent la plupart des projets consiste à intégrer un nom d'utilisateur et un mot de passe partagés dans chaque appareil. Cela fonctionne le premier jour et pose problème ensuite :
- Un seul appareil compromis expose toute la flotte.
- Vous ne pouvez pas révoquer un seul appareil sans reflasher tous les autres.
- Les journaux ne peuvent pas vous dire quel appareil s'est mal comporté.
Les identifiants par appareil règlent ces trois problèmes. Sur un broker Mosquitto auto-hébergé, vous maintiendriez un fichier de mots de passe :
# Créer le fichier avec le premier utilisateur, puis en ajouter d'autres sans -c
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
Le fichier stocke des hachages salés, et non les mots de passe eux-mêmes, et le broker doit être rechargé après chaque modification. Gérer cela vous-même implique aussi de renouveler le certificat TLS et de synchroniser le fichier entre les instances.
Des identifiants par appareil sur ConnectMQ
Avec ConnectMQ, le broker génère les identifiants pour vous. Lorsque vous créez un broker dans le portail, vous recevez un nom d'utilisateur, un mot de passe et un client ID, et le client ID est lié aux identifiants délivrés. Ce lien est important : un mot de passe volé ne peut pas être utilisé avec un client ID arbitraire, et deux appareils ne peuvent pas partager silencieusement un même jeu d'identifiants, car ils se disputeraient la même identité liée.
Pratiques recommandées sur un broker MQTT managé :
- Délivrez un jeu d'identifiants distinct pour chaque appareil ou service, et notez quel appareil physique détient quel client ID.
- Stockez le mot de passe dans un stockage protégé sur l'appareil, pas dans le code source. Consultez sécuriser les identifiants MQTT sur les appareils.
- Connectez-vous uniquement sur les ports 8883 ou 8084 avec vérification du certificat.
- Anticipez les changements : le guide de rotation des identifiants montre comment remplacer les identifiants de toute une flotte sans interruption de service.
Les locataires sont isolés les uns des autres : les identifiants délivrés pour votre broker ne donnent accès qu'au trafic de votre broker. Les quotas et la protection contre les rafales s'appliquent par offre, ce qui limite les dégâts qu'un client compromis peut causer.
Identifiant et mot de passe face aux autres méthodes
| Méthode | Point fort | Point faible |
|---|---|---|
| Identifiant et mot de passe sur TLS | Simple, pris en charge par toutes les bibliothèques clientes | Secret statique ; doit être stocké et renouvelé |
| Certificats clients (mTLS) | Identité forte, aucun secret partagé sur le réseau | Cycle de vie des certificats et PKI à exploiter |
| JWT dans le champ mot de passe | Durée de vie courte, transporte des claims | Nécessite un émetteur de jetons et une horloge synchronisée sur les appareils |
Pour la plupart des flottes, des mots de passe uniques par appareil sur un TLS vérifié constituent une base solide. Le guide des bonnes pratiques de sécurité MQTT couvre les couches qui viennent s'y ajouter.
Démarrer avec ConnectMQ
Oubliez les fichiers de mots de passe et les renouvellements de certificats. Un broker MQTT managé par ConnectMQ vous offre TLS sur les ports 8883 et 8084, des identifiants générés liés aux client ID et le blocage des adresses IP après des échecs de connexion répétés. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire.
Questions fréquentes
L'authentification MQTT par identifiant et mot de passe est-elle sûre ?
Elle est suffisamment sûre pour la plupart des déploiements lorsqu'elle est utilisée sur TLS avec vérification du certificat et des mots de passe uniques par appareil. Sur TCP en clair, port 1883, le mot de passe est visible par quiconque peut capturer le trafic.
MQTT chiffre-t-il le mot de passe ?
Non. MQTT envoie le mot de passe sous forme d'octets bruts dans le CONNECT. Le chiffrement provient uniquement de la couche TLS qui entoure la connexion.
Puis-je me connecter au serveur MQTT public gratuit avec un nom d'utilisateur et un mot de passe ?
Le serveur MQTT public gratuit broker.connectmq.com, réservé aux tests et aux prototypes, accepte les connexions anonymes avec n'importe quel client ID unique non vide. Pour un trafic authentifié et privé, créez votre propre broker et utilisez les identifiants générés.
Quelle est la différence entre 0x86 et 0x87 ?
0x86 signifie que le nom d'utilisateur ou le mot de passe était erroné. 0x87 signifie que les identifiants ont été reconnus, mais que le client n'est pas autorisé à se connecter ou à effectuer l'action.
