MQTT security

Run a loopback-only Mosquitto practice broker, give a sensor and reader different permissions, and test the denied cases.

Communicating devices

Ingredients

Follow a part’s name for an introduction and compatibility notes.

MQTT clients publish messages to topics through a broker. A password identifies a client; an access-control list decides which topics it may use. This exercise gives a pretend sensor permission to publish one topic and a monitor permission to read it.

Prepare an isolated practice directory

Install Mosquitto and its command-line clients using the official download guidance for your system. This recipe targets Mosquitto 2.0.x; check mosquitto -h. If using a newer release, follow its version-specific authentication guidance. Leave any system broker service alone and run this instance as your ordinary user on a different port.

mkdir novelide-mqtt-lab
cd novelide-mqtt-lab
umask 077
mosquitto_passwd -c passwords sensor
mosquitto_passwd passwords monitor
pwd

Enter separate, disposable practice passwords when prompted. Use -c only when creating the file: repeating it would replace the existing users. Note the absolute directory printed by pwd.

Write the policy and configuration

Create acl in that directory:

user sensor
topic write lab/desk/temperature

user monitor
topic read lab/desk/temperature

Create mosquitto.conf, replacing both example paths with the absolute paths on your machine:

listener 18883 127.0.0.1
allow_anonymous false
password_file /absolute/path/novelide-mqtt-lab/passwords
acl_file /absolute/path/novelide-mqtt-lab/acl
persistence false
mosquitto -c ./mosquitto.conf -v

The listener accepts IPv4 loopback connections from this computer only. Password authentication does not encrypt MQTT. That is why this plaintext lab stays on loopback and uses disposable credentials.

Prove the allowed and denied cases

In a second terminal, subscribe as the monitor. In a third, publish as the sensor. Replace the uppercase password placeholders with your practice values. These CLI arguments can appear in shell history and process listings; do not use reusable credentials here.

mosquitto_sub -h 127.0.0.1 -p 18883 -V mqttv5 -u monitor -P MONITOR_TEST_PASSWORD -t lab/desk/temperature -v
mosquitto_pub -h 127.0.0.1 -p 18883 -V mqttv5 -u sensor -P SENSOR_TEST_PASSWORD -t lab/desk/temperature -m '23.5' -q 1 -d

The subscriber should display the topic and 23.5. Now change the publisher username and password to the monitor’s credentials, keeping the topic and QoS 1. The monitor must not publish successfully. Use the MQTT 5 acknowledgment and broker log to inspect the denial; a client connecting successfully does not prove its publication was allowed.

  • Publish as the sensor to lab/other/temperature: denied.
  • Subscribe without a username and password: connection rejected.
  • Connect using a wrong password: rejected.
  • Restore the permitted sensor publication: the monitor receives it again.

If the broker cannot read a file, check the absolute paths and which user runs it. If the port is occupied, choose another unused port in both configuration and clients. Stop the foreground broker with Ctrl+C when finished.

Before moving beyond this computer

Do not simply change the listener address and reuse the plaintext setup. Configure TLS, a certificate valid for the broker hostname, and client trust in its issuing CA; verify that wrong hostnames and untrusted certificates fail. A properly managed private CA can provide valid authentication. Disabling certificate checks defeats that authentication.

Give deployed devices unique credentials, keep secret files readable only by the required accounts, and test revocation. Decide how availability, retained readings, and stale values work. Use the Mosquitto authentication guide and the configuration reference for your installed release for the next deployment stage.