In the previous articles of this series , we mentioned that with the help of the Username and Password fields in the MQTT CONNECT message, we can implement some simple authentication, such as password authentication, token authentication, etc. In order to further ensure the security of the IoT system, in this article, we will learn about another authentication mechanism: enhanced authentication.
What is Enhanced Authentication?
Enhanced authentication is a new authentication mechanism introduced by MQTT 5.0. In fact, we use the authentication framework to describe it more appropriately, because it allows us to apply various authentication methods that are more secure than password authentication.
More secure, on the other hand, means more complex, such authentication methods such as SCRAM usually require more than one round trip of authentication data. This makes the round-trip authentication framework provided by the CONNECT and CONNACK messages no longer applicable, so MQTT 5.0 specially adds the AUTH message for this purpose, which can support any number of round-trips of authentication data. This allows us to introduce a challenge-response style SASL mechanism into MQTT.
What problem does Enhanced Authentication solve?
Before we talk about this issue, we need to know, why is password authentication still not secure enough?
In fact, even if we have used salting and hashing to store passwords, the security of password storage has been improved as much as possible. But in order to complete the authentication, the client has to transmit the password in clear text in the network, which makes the password have the risk of being leaked. Even if we use TLS to encrypt communication, it is still possible for attackers to steal sensitive data such as passwords due to the use of lower SSL versions, insecure cipher suites, illegal CA certificates, and so on.
In addition, simple password authentication can only allow the server to verify the identity of the client, but cannot allow the client to verify the identity of the server, which makes it possible for attackers to impersonate the server to obtain sensitive data sent by the client. And this is what we usually call a man-in-the-middle attack.
Through enhanced authentication, we can choose to use more secure authentication methods under the SASL framework. Some of them can avoid the transmission of passwords in the network, some can allow the client and server to verify each other's identity, and some of them are both. equipment, it still depends on the authentication method we finally choose.
Common SASL mechanisms that can be used to enhance authentication
DIGEST-MD5
DIGEST-MD5 is an authentication mechanism under the Simple Authentication Security Layer (SASL) framework. It is based on the MD5 (Message Digest 5) hash algorithm and uses a challenge-response mechanism to verify the identity between the client and the server. Its advantage is that the client does not need to transmit the password in clear text over the network.
To put it simply, when a client requests to access a protected resource, the server will return a Challenge, which contains a one-time random number and some necessary parameters. The client needs to use these parameters plus the username and password it holds. Wait for the data, generate a response and return it to the server, the server will generate the expected response in exactly the same way, and then compare it with the received response, if the two match, the authentication is passed. This eliminates the risk of password leaks due to network eavesdropping, and because a one-time random number is used when connecting, it also enhances the defense against replay attacks.
However, it should be noted that DIGEST-MD5 only provides server-to-client authentication, but does not provide client-to-server authentication, so it cannot prevent man-in-the-middle attacks. In addition, since MD5 is no longer safe, it is recommended to use a hash function with stronger collision resistance such as SHA-256 to replace it.
SCRAM
SCRAM is also an authentication mechanism under the SASL framework. Its core idea is similar to that of DIGEST-MD5. It also uses a one-time random number to require the client to generate a response, so the client does not need to transmit the plaintext password on the network. But unlike DIGEST-MD5, SCRAM introduces Salt and Iterations, and uses more secure hash algorithms such as SHA-256 and SHA-512, which brings higher security Resilience enables SCRAM to store passwords more securely and reduces the risk of being cracked by offline attacks, replay attacks, or other attacks.
In addition, SCRAM uses a more complex challenge-response process, which adds a process in which the server sends a certificate to the client. The client can use this certificate to confirm whether the server holds the correct password, which realizes the client Authentication of the server reduces the risk of man-in-the-middle attacks.
Of course, hash algorithms such as SHA256 used by SCRAM also bring some additional overhead in performance, which may have a certain impact on some resource-constrained devices.
Kerberos
Kerberos introduces a trusted third-party Kerberos server to provide authentication services. The Kerberos server grants tickets to authenticated users, and users use the tickets to access resource servers. One of the benefits brought about by this is that users can gain access to multiple systems and services as long as they pass one authentication, that is, the single sign-on (SSO) function is realized.
The life cycle of the ticket granted by the Kerberos server is limited, and the client can only use this ticket to access the service within a limited time, which can avoid security problems caused by ticket leakage. Of course, although a shorter validity period can effectively improve security, it may not be friendly in terms of convenience of use, and we need to balance the two by ourselves.
The core of Kerberos is a symmetric encryption algorithm. The server uses the locally stored password hash to encrypt the authentication data, and then returns it to the client. The client hashes the password it holds and then decrypts the authentication data. The advantage of this is that it does not need to transmit the password in clear text on the network, and it allows the server and the client to mutually verify that each other has the correct password. In this way of exchanging data through symmetric encryption, the server and the client can also securely complete the sharing of the session key, which can be used to encrypt subsequent communication data to provide security protection for the communication data.
While Kerberos provides strong security, it also brings considerable complexity. There are certain thresholds in its implementation and configuration. In addition, up to six handshakes also put forward relatively high requirements for network delay and reliability. , so usually Kerberos is mainly used in the enterprise intranet environment.
How does enhanced authentication work in MQTT?
Taking the SCRAM mechanism as an example, let's take a look at how enhanced authentication is performed in MQTT. As for the specific principles of SCRAM, this article will not expand. Here, we only need to know that SCRAM needs to transmit four messages to complete the authentication:
- client-first-message
- server-first-message
- client-final-message
- server-final-message
First of all, the client still needs to send a CONNECT message to initiate authentication, but it needs to set the Authentication Method attribute to SCRAM-SHA-256 to indicate that it wants to use SCRAM authentication, where SHA-256 indicates the hash function to be used, and at the same time use Authentication Data The attribute holds the content of client-first-message. Authentication Method determines how the server should parse and process the data in Authentication Data.
If the server does not support SCRAM authentication, or finds that the content of the client-first-message is invalid, it will return a CONNACK message containing a Reason Code indicating the reason for the authentication failure, and then close the network connection.
Otherwise, the server will proceed to the next step: return an AUTH message, and set the Reason Code to 0x18, which means continuing the authentication. The Authentication Method in the message will be the same as in the CONNECT message, and the Authentication Data attribute will contain the content of server-first-message.
After confirming that the content of server-first-message is correct, the client also returns an AUTH message with Reason Code 0x18, and the Authentication Data attribute will contain the content of client-final-message.
After the server confirms that the content of the client-final-message is correct, the server has completed the verification of the client's identity. So this time the server will no longer return an AUTH message, but a CONNACK message with a Reason Code of 0 to indicate successful authentication, and pass the final server-final-message through the Authentication Data attribute in the message. The client needs to verify the identity of the server based on the content of this message.
If the identity of the server is verified, the client can start subscribing to topics or publishing messages, and if not, the client will send a DISCONNECT message to terminate this connection.
epilogue
Enhanced authentication offers users the possibility to introduce more authentication methods. You can choose an authentication method that suits your specific needs, further enhancing system security.
As a widely used MQTT Broker, EMQX is known for its high scalability and availability, but also always puts user security in the first place. In addition to password-based authentication, EMQX also supports enhanced authentication. Users can enable SCRAM authentication through EMQX to increase the security level of their MQTT infrastructure.
For more information, please see: MQTT 5.0 Enhanced Authentication
Copyright statement: This article is original by EMQ, please indicate the source for reprinting.
Original link: https://www.emqx.com/zh/blog/leveraging-enhanced-authentication-for-mqtt-security