Webinar
数字社交:EMQ 与 JAGAT 探讨社交行业数据潜能 →

MQTT 5.0 中的安全认证机制:增强认证介绍

Zibo Zhou
2023-6-13
MQTT 5.0 中的安全认证机制:增强认证介绍

在本系列之前的文章中我们提到,借助 MQTT CONNECT 报文中的 Username 和 Password 字段,我们可以实现一些简单的认证,比如密码认证、Token 认证等。为了进一步保障物联网系统的安全,在本期文章中,我们将一起了解另一种认证机制:增强认证。

什么是增强认证?

增强认证是 MQTT 5.0 新引入的认证机制。事实上,我们用认证框架来形容它更为适合,因为它允许我们套用各种比密码认证更加安全的身份验证方法。

不过更安全,另一方面则意味着更复杂,这类身份验证方法例如 SCRAM 通常都要求一次以上的认证数据往返。这导致由 CONNECT 与 CONNACK 报文提供的一次往返的认证框架变得不再适用,所以 MQTT 5.0 专门为此新增了 AUTH 报文,它能够支持任意次数的认证数据的往返。这使得我们可以将质询-响应风格的 SASL 机制引入到 MQTT 中。

增强认证解决了什么问题?

在我们谈论这个问题之前,我们需要知道,为什么密码认证仍然不够安全?

事实上,即使我们已经使用加盐与哈希的方式来存储密码,尽可能提升了密码存储的安全性。但是为了完成认证,客户端不得不在网络中明文传输密码,这就使密码有了被泄漏的风险。即使我们使用 TLS 加密了通信,也仍有可能因为使用了较低的 SSL 版本、不够安全的密码套件、不合法的 CA 证书等等原因导致被攻击者窃取到密码这类敏感数据。

另外,简单的密码认证只能让服务端验证客户端的身份,却不能让客户端验证服务端的身份,这使得攻击者有机会冒充服务端来获取客户端发送的敏感数据。而这就是我们通常所说的中间人攻击。

而通过增强认证,我们可以选择使用 SASL 框架下的安全性更强的认证方法,它们有些可以避免在网络中传输密码,有些可以让客户端和服务端互相验证对方的身份,有些则两者皆备,这仍取决于我们最终选择的认证方法。

常见的可用于增强认证的 SASL 机制

DIGEST-MD5

DIGEST-MD5 是在简单认证安全层(SASL)框架下的一种身份验证机制。它基于 MD5(Message Digest 5)散列算法,使用质询-响应机制来验证客户端和服务器之间的身份。它的优点在于客户端不需要在网络上传输明文密码。

简单来说,就是当客户端请求访问受保护资源时,服务端将返回一个 Challenge,其中包含了一次性的随机数和一些必要参数,客户端需要使用这些参数加上自己持有的用户名密码等数据,生成一个响应并返回给服务端,服务端将使用完全相同的方式生成期望的响应,然后与收到的响应进行比较,如果两者匹配,则身份验证通过。这免去了密码因为遭到网络窃听而泄漏的风险,并且由于连接时使用的是一次性的随机数,所以也增强了对重放攻击的防御能力。

但需要注意,DIGEST-MD5 只提供了服务端对客户端的身份验证,但没有提供客户端对服务端的身份验证,所以它并不能防止中间人攻击。另外,由于 MD5 目前已经不再安全,所以更推荐使用 SHA-256 这类抗碰撞能力更强的哈希函数来替代它。

SCRAM

SCRAM 同样是 SASL 框架下的一种身份验证机制,它的核心思想与 DIGEST-MD5 类似,同样是使用一次性的随机数要求客户端生成响应,所以客户端同样无需在网络上传输明文密码。但与 DIGEST-MD5 不同的是,SCRAM 引入了盐值(Salt)和迭代次数(Iterations),并且使用了 SHA-256、SHA-512 这些更安全的哈希算法,这带来了更高的安全性,使 SCRAM 能够更加安全地存储密码,并且减少被离线攻击、重放攻击或其他攻击破解的风险。

另外,SCRAM 使用了更复杂的质询-响应流程,它增加了一个服务端向客户端发送证明的过程,客户端可以通过这个证明来确认服务端是否持有正确的密码,这就实现了客户端对服务端的身份验证,降低了中间人攻击的风险。

当然,SCRAM 使用的 SHA256 等哈希算法,也在性能上带来了一些额外的开销,这可能会对一些资源受限的设备造成一定的影响。

Kerberos

Kerberos 引入了一个可信的第三方 Kerberos 服务器来提供身份验证服务,Kerberos 服务器向通过验证的用户授予票据,用户再使用票据访问资源服务器。这带来的一个好处是用户只要通过一次身份验证,就可以获得多个系统和服务的访问权限,即实现了单点登录(SSO)的功能。

Kerberos 服务器授予的票据的生命周期是有限的,客户端只能在有限时间的内使用这个票据访问服务,这可以避免因票据泄漏而导致的安全问题。当然,虽然较短的有效期可以有效地提高安全性,但在使用的便利性上可能不太友好,我们需要自行权衡这两者。

Kerberos 的核心是对称加密算法,服务端使用本地存储的密码哈希加密认证数据,然后返回给客户端。客户端对自己持有的密码进行哈希然后解密这些认证数据,这样的好处是无需在网络上明文传输密码,又能够让服务端和客户端相互验证对方都持有正确的密码。以这种通过对称加密交换数据的方式,服务端和客户端还能够安全地完成会话密钥的共享,这个密钥可以被用于后续通信数据的加密,以提供对通信数据的安全保护。

Kerberos 在提供较强安全性的同时,也带来了相当的复杂性,它的实现和配置都存在一定的门槛,另外多达六次的握手对于网络延迟和可靠性也提出了比较高的要求,所以通常 Kerberos 主要在企业的内网环境中使用。

增强认证在 MQTT 中是如何运行的?

以 SCRAM 机制为例,我们来看一下在 MQTT 中增强认证是如何进行的。至于 SCRAM 的具体原理本文不作展开,在这里,我们只需要知道,SCRAM 需要传递四次消息才能完成认证:

  • client-first-message
  • server-first-message
  • client-final-message
  • server-final-message

MQTT 增强认证

首先,客户端仍然需要发送 CONNECT 报文来发起认证,只是需要将 Authentication Method 属性设置为 SCRAM-SHA-256 表示想要使用 SCRAM 认证,其中 SHA-256 表示准备使用的哈希函数,同时使用 Authentication Data 属性存放 client-first-message 的内容。Authentication Method 决定了服务端应该如何解析和处理 Authentication Data 中的数据。

如果服务端不支持 SCRAM 认证,或者发现 client-first-message 的内容不合法,那么它将返回包含指示认证失败原因的 Reason Code 的 CONNACK 报文,然后关闭网络连接。

反之服务端就会继续进行下一步:返回一个 AUTH 报文,并且将 Reason Code 设置为 0x18,表示继续认证。报文中的 Authentication Method 将与 CONNECT 报文相同,而 Authentication Data 属性将包含 server-first-message 的内容。

客户端在确认 server-first-message 的内容无误后,同样返回一个 Reason Code 为 0x18 的 AUTH 报文,Authentication Data 属性将包含 client-final-message 的内容。

在服务端确认 client-final-message 的内容无误后,服务端就已经完成了对客户端身份的验证。所以这次服务端将不再是返回 AUTH 报文,而是返回一个 Reason Code 为 0 的 CONNACK 报文以表示认证成功,并通过报文中的 Authentication Data 属性传递最终的 server-final-message。客户端需要根据这个消息的内容来验证服务端的身份。

如果服务端的身份通过了验证,那么客户端就可以开始订阅主题或者发布消息了,而如果没有通过验证,客户端将会发送 DISCONNECT 报文来终止这一次的连接。

结语

增强认证为用户提供了引入更多身份验证方法的可能性。您可以选择适合您特定需求的认证方法,进一步增强系统的安全性。

作为广泛使用的 MQTT BrokerEMQX 在以其高可扩展性和可用性著称的同时,也始终将确保用户安全放在首位。除了基于密码的认证,EMQX 也支持增强认证。用户可以通过 EMQX 启用 SCRAM 认证,以提高其 MQTT 基础设施的安全级别。

更多信息请查看:MQTT 5.0 增强认证

免费试用 EMQX Cloud
全托管的 MQTT 消息云服务
开始试用 →

推荐阅读

2023-7-20EMQX Team
通过速率限制保障 MQTT 服务器的稳定与安全

速率限制限制和平衡流量的能力,除了能够应对正常业务变化带来的流量波动,还能够防止攻击者恶意消耗服务端资源。本文将探讨它如何为物联网平台和应用提供安全上的保障。

2022-8-18EMQX Team
灵活多样认证授权,零开发投入保障 IoT 安全

本文将通过对 EMQX 客户端认证与授权机制以及 5.0 版本中相关优化的详细解析,为读者展示 EMQX 进行物联网安全保障的原理机制,帮助大家更好地使用这一功能构建更加安全可靠的物联网平台与应用。