MQTT – Security

by luca

In the IoT they often don’t give much importance to the security aspects of the communcation. Proof of this is that many of the latest DDOS (Distributed Denial of Service) attacks have been launched by hacked Internet-connected smart devices.

In the previous posts, you learned how to configure mosquitto to receive messages published by clients and to forward them to all the subscribers. Today I’m going to show you how to configure the application security of your MQTT broker.

This post is about the standard settings mosquitto offers. On the Internet you can find several plugins to extend its functionalities and to implement advanced security settings, like storing accounts in different backends or using json web tokens.


The first step to make our broker secure is to require clients who are connecting to authenticate themselves. In this way, only authorized clients can send/receive messages.

Open the mosquitto.conf file and, first of all, disable the anonymous access setting to false the corresponding parameter.


When you change a setting in the file, make sure that the hash (#) character is not present at the beginning of the line, otherwise the parameter is not considered

The list of the users authorized to connect to the broker is defined in a dedicated file. The name of this file is configured with the password_file parameter (in the example below, the file containing users and passwords is named “pwdfile”, stored in the same folder of mosquitto):


Using the mosquitto_passwd.exe command you can create (-c) the file and add a new user (“luca”). The command will ask to type the user’s password twice:


If you need to add additional users, you can run the command again, without the -c option:

mosquitto_passwd.exe pwdfile sara

Let’s try the new configuration. First run mosquitto specifying the configuration file (mosquitto.exe -c mosquitto.conf), then try to publish a message as you learned in the previous tutorials:


You can see that the connection is refused because of the client is not authorized: we indeed didn’t specify any users and anonymous access was disabled.

Try to run the command again, this time specifying the correct user and password and you’ll find that the message will be correctly published:

mosquitto_pub.exe -u <utente> -P <password> -t home/bedroom/temp -m 19


After having defined who can connect to the broker, it’s now time to define what a user can do once connected. Again, the configuration of the ACLs (access control lists) is in a dedicated file, whose name is configured with the acl_file parameter:


The ACL file contains blocks with the following structure:

  • the first line, user <nomeutente>, that defines the user the following ACLs are applied to
  • one or more lines, topic <read|write|readwrite> <nometopic>, that define which actions the user above can do on the specified topic

Let’s see an example, a file in which we define a user (writeclient) that can send messages to the secure/data topic and a user (readclient) that can read those messages. Both the two users can in addition send an receive messages from all the open/# topic (for an explanation about the use of wildcards read my previous post):


(lines starting with # are comments)

Let’s now try to send a message using the readclient user, who’s not allowed to do that:


The client doesn’t get any error message, but in the mosquitto logs you can clearly see that the publish command was denied, consistent with the configured ACLs.

If instead the right users are specified, the message is correctly routed from the publishing client to the subscribing one:



It’s very important to secure our broker, especially if it’s connected to a public network (for example if it’s available on the Internet). In today’s blog post you learned how to define users and grants in mosquitto.

Related Posts


Cristian Monday December 19th, 2016 - 02:14 PM

Ciao Luca,
complimenti per l’ottima esposizione: chiara, lineare e veramente semplice. Mi hai fatto scoprire questa immensa potenzialità offerta da MQTT. Per completare il “pacchetto”, sarebbe bello valutare anche la soluzione in SSL al fine di rendere ancora più sicure le comunicazioni tra borker e devices.
Colgo l’occasione per augurare a te e famiglia buone feste e felice 2017!

luca Monday December 19th, 2016 - 03:48 PM

Grazie Cristian! Ho sicuramente in cantiere un articolo relativo all’SSL, solo non con Arduino (troppo poco potente) ma con esp32 o altra piattaforma + evoluta.

Reply – ESP32 (28) – MQTT e SSL Monday December 4th, 2017 - 09:24 AM

[…] il tema sicurezza per i broker MQTT. In un precedente articolo, vi ho mostrato come gestire autenticazione e autorizzazione. La debolezza di tale configurazione […]


Leave a Comment

14 − two =