📚 课程目录第2章 MQTT协议身份标识机制

2. MQTT协议身份标识机制

MQTT 的 CONNECT 报文是客户端与 Broker 建立会话的唯一入口，身份标识信息全部承载在这个报文中。理解 Client ID、Username、Password 三个字段各自的协议语义，是判断"认证是否可靠"的前提。很多部署事故并非密码泄露，而是把这三个字段的职责混用：用 Client ID 当账号、把 Username 当设备编号、把 Password 当会话令牌，最终导致 ACL 无法精确落地。

三个字段的协议语义

Client ID 是 MQTT 协议层面的会话标识，长度 1～23 字节（MQTT 3.1 规范要求，3.1.1 起放宽为 Broker 可接受更长），字符集建议使用 0-9、a-z、A-Z。它的核心作用是让 Broker 识别"这是同一个客户端"，从而决定是否复用会话状态（Clean Session=false 时的订阅关系、未确认的 QoS 1/2 消息、离线消息队列）。Client ID 在协议中不是认证凭据，任何人都可以声明任意 Client ID；如果 Broker 不校验，攻击者用相同 Client ID 连接会直接顶掉合法客户端的会话，形成"会话劫持"。

Username 是 UTF-8 字符串，协议只规定它"存在且可被 Broker 读取"，不规定其含义。工程实践中它通常承担"身份主体"的角色，例如设备序列号、租户账号、应用名。ACL 规则一般以 Username 作为主体维度，例如"允许 Username=device-001 订阅 sensors/device-001/#"。

Password 是二进制字段（MQTT 3.1.1 中为 binary data），协议同样不规定其内容。它可以是明文口令、口令的哈希、HMAC 签名、JWT，甚至一次性 Token。协议只负责把它原样送到 Broker，是否校验、如何校验完全由 Broker 的认证插件决定。

关键结论：MQTT 协议本身只提供"字段承载能力"，不提供"认证强度"。三个字段的语义由 Broker 的认证与授权实现来定义，协议层只保证它们能被送达。

明文传输风险：字段在 TCP 上完全暴露

MQTT 默认运行在 TCP 1883 端口，CONNECT 报文以明文形式发送。这意味着 Client ID、Username、Password 三个字段在链路上是可直接读取的字节序列。用 tcpdump 抓包即可看到：

# 在客户端所在主机抓取 1883 端口流量
tcpdump -i eth0 -A -s 0 'tcp port 1883 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x10000000)'

# 典型输出片段（CONNECT 报文载荷）
\x10\x2a\x00\x04MQTT\x04\xc2\x00\x3c
\x00\x0bdevice-0001        <- Client ID
\x00\x08factory-a         <- Username
\x00\x0cP@ssw0rd2024      <- Password（明文可见）

风险不止于"密码被看到"。明文链路下，攻击者可以：

窃听：直接获得 Username/Password，用于伪造连接。
篡改：中间人修改 CONNECT 中的 Client ID，把合法设备顶下线。
重放：如果 Password 是静态口令，抓包后可无限次重放，Broker 无法区分。
会话劫持：结合 Client ID 可预测（如 device-0001 递增），批量伪造连接。

需要特别指出：即使 Password 在应用层做了哈希，明文链路上的哈希值本身就是一个"可重放的凭据"。哈希只防止口令原文泄露，不防止认证重放。因此"在客户端做哈希"不能替代传输层加密。

TLS 的补偿作用与边界

TLS（通常 MQTT over TLS 使用 8883 端口）在 TCP 与 MQTT 之间建立加密通道，对 CONNECT 报文整体加密，从而补偿明文传输的三类风险：

机密性：Client ID、Username、Password 在链路上不可读，抓包只能看到 TLS 记录层密文。
完整性：TLS 的 MAC/AEAD 保证 CONNECT 字段不被篡改，中间人无法悄悄替换 Client ID。
服务器身份：客户端通过校验 Broker 证书，确认自己连的是真实 Broker，而非伪造的钓鱼 Broker。

但 TLS 的补偿有明确边界，不能把它当成万能药：

不解决弱口令：TLS 保护传输，不保护"Password=123456"。攻击者若已获得口令（如从固件中提取），仍可正常连接。
不解决重放：若 Password 是静态值，攻击者拿到后仍可重放；需要配合一次性 Token 或 HMAC 挑战机制。
不解决 Client ID 冲突：TLS 不校验 Client ID 唯一性，Broker 仍需实现"同 Client ID 踢线"策略。
单向 TLS 的局限：只验证服务器证书时，Broker 无法确认客户端身份，仍需 Username/Password 或客户端证书。
证书管理成本：设备量大时，证书签发、轮换、吊销的运维复杂度显著高于口令。

字段组合与安全承载能力对照

下表给出常见组合方式及其安全承载能力，便于在方案设计时快速判断。表中"承载能力"指该组合在 TLS 加持下能抵抗的主要威胁。

Client ID	Username	Password	典型用途	安全承载能力
设备序列号	租户/产品线	静态口令	小型内网设备	弱：口令泄露即失守，需 TLS + 定期轮换
设备序列号	设备序列号	HMAC 签名	中等规模设备	中：可防重放（带时间戳），需时钟同步
随机 UUID	账号	JWT	移动 App / Web	强：可携带过期时间与权限声明
随机 UUID	—	—	仅客户端证书认证	强：依赖 mTLS，Client ID 仅作会话标识
设备序列号	设备序列号	一次性 Token	高安全场景	强：Token 用后失效，需 Broker 支持

实践建议：让三个字段各司其职

结合上述分析，落地时建议遵循以下原则：

Client ID 只做会话标识：使用不可预测的随机值或设备唯一序列号，禁止用递增数字；Broker 开启"同 Client ID 踢线"并记录日志。
Username 做身份主体：与 ACL 规则一一对应，命名规范如 tenant/device-type/serial，便于规则匹配与审计。
Password 做凭据载体：优先使用短期 Token 或 HMAC 签名，避免长期静态口令；若必须用口令，长度≥16 且定期轮换。
强制 TLS：生产环境禁用 1883 明文端口，或仅在内网隔离区保留并配合网络层防护。
认证与授权分离：认证解决"你是谁"，ACL 解决"你能做什么"，两者不要混在同一个字段里。

判断一个 MQTT 部署是否安全，可以先问三个问题：CONNECT 是否走 TLS？Password 是静态口令还是短期凭据？Client ID 是否可被预测？三个问题中任意一个答案为"否"，就存在可被利用的攻击面。

回到协议本身：Client ID、Username、Password 只是三个"容器"，协议不保证容器里装的是什么，也不保证容器在链路上是否被保护。真正的安全来自三件事的叠加——用 TLS 保护传输、用短期凭据抵抗重放、用 Broker 的认证与 ACL 实现把身份映射到权限。三者缺一，身份标识机制就只是"形式上的标识"，而非"可依赖的认证"。