Authentication with Username and Password - MQTT Security Fundamentals
Authentication is part of the transport and application level security in MQTT. With Transport Layer Security (TLS), the successful validation of a client certificate is used to authenticate the client to the server. On the application level, the MQTT protocol provides username and password for authentication. Different broker implementations exist in addition to these levels. This blog gives you an overview of authentication in general and the authentication capabilities that are built into the MQTT protocol specifically. In our next blog, we look at different approaches that broker implementations take with authentication.
Authentication
According to Wikipedia:
Authentication is the act of confirming the truth of an attribute of a single piece of data or entity.
In short, authentication verifies whether a person, device or application is who they say they are.
Air travel is a classic example of authentication: Before you are permitted to board a plane, airport security asks you to present appropriate identification. For example, your passport. The passport authenticates you as the person to whom the airline issued the ticket. Your passport verifies your identity and your name. Anyone can state your name, but only you can provide your passport as proof of your identity.
We use authentication processes everyday without even noticing. Every time you log into your computer, you provide a username and a password. The username states your identity and entry of the password authenticates you as the rightful owner of that identity.
MQTT Authentication with Username/Password
The MQTT protocol provides username and password fields in the CONNECT message for authentication. The client has the option to send a username and password when it connects to an MQTT broker. For more details, see MQTT Essentials: Establishing an MQTT connection.
The username is an UTF-8 encoded string. The password is binary data with a maximum of 65535 bytes. The MQTT specification states that you can send a username without password, but it is not possible to send a password without username. MQTT version 3.1.1 also removes the previous recommendation for 12 character passwords.
When you use the built-in MQTT username/password authentication, the MQTT broker evaluates credentials based on the authentication mechanism that is implemented (more on that in the next post) and returns one of the following return codes:
| Return Code | Return Code Response |
|---|---|
| 0 | Connection Accepted |
| 4 | Connection Refused, bad user name or password |
| 5 | Connection Refused, not authorized |
For a full list of all return codes, see MQTT Essentials: Establishing an MQTT connection.
When the username and password are set on the client, the information is sent to the broker in plain text. This text is vulnerable to eavesdropping and provides an easy way for attackers to obtain the credentials. Secure transmission of usernames and passwords requires transport encryption.
In our next post, we look at advanced authentication mechanisms to implement authentication on the broker side. For example, verifying the provided username and password or using attributes such as the client identifier for the authentication.
We hope you are enjoying our MQTT Security Fundamentals. Subscribe to our RSS feed to get notified of our new content. As always, feel free to use the comments for suggestions or questions.
Do watch our webinar discussing IoT security issues and how MQTT can actually mitigate security vulnerabilities in IoT and IIoT infrastructures.
HiveMQ Team
The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.
