共计 3456 个字符，预计需要花费 9 分钟才能阅读完成。
在本系列之前的文章中咱们提到，借助 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
首先，客户端依然须要发送 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 Broker，EMQX 在以其高可扩展性和可用性著称的同时，也始终将确保用户平安放在首位。除了基于明码的认证，EMQX 也反对加强认证。用户能够通过 EMQX 启用 SCRAM 认证，以进步其 MQTT 基础设施的安全级别。
更多信息请查看：MQTT 5.0 加强认证
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.com/zh/blog/leveraging-enhanced-authentication-for-mqtt-security