📚 课程目录第3章用户名/密码认证加固

3. 用户名/密码认证加固：别让凭证成为突破口

用户名/密码认证，是MQTT最基础的防线。但说实话，很多项目就栽在这道最基础的防线上。我见过太多设备直接用admin/123456上线的案例，嗯，那感觉就像把家门钥匙挂在门外。

这一章，我们深入聊聊怎么把这道防线真正筑牢。不是简单设个密码就完事，而是从密码策略、存储安全、传输保护三个维度，把凭证安全做到位。

3.1 密码复杂度策略：别让字典攻击得逞

你想想看，如果设备密码是password或者123456，攻击者用现成的字典库，几秒钟就能扫出来。我在一次物联网安全审计中遇到过，某智能水表厂商所有设备出厂密码都是smartmeter2020，结果被攻击者批量控制，直接篡改上报数据。

密码复杂度，不是给用户添麻烦，而是给攻击者设门槛。我个人习惯，对于MQTT设备密码，至少要求满足以下条件：

长度不低于12位——8位密码在GPU暴力破解下，几小时就能跑完；12位以上，破解时间呈指数级增长
包含三类以上字符——大写字母、小写字母、数字、特殊符号，至少选三类
不能包含用户名、设备ID、厂商名——这些信息往往公开可查
不能是常见密码变体——比如P@ssw0rd这种，字典里早收录了

核心原则：密码的熵值（信息熵）至少要达到60比特以上。12位随机字符密码，熵值大约在72比特左右，基本够用。

但这里有个坑——设备端往往没有交互界面，怎么让用户设置复杂密码？我建议的做法是：

出厂预置随机密码——每台设备出厂时，由产线系统生成随机密码，写入设备并打印在标签上
首次登录强制修改——设备首次联网后，强制用户通过安全通道修改密码
密码强度实时校验——如果设备有Web管理界面，前端+后端双重校验密码强度

小技巧：可以用zxcvbn库（Dropbox开源的密码强度评估库）来评估密码强度，比简单的正则匹配靠谱得多。

3.2 密码存储的哈希加盐技术：数据库泄露也不怕

这是最容易被忽视的一环。很多开发者觉得「密码存在数据库里，别人又看不到」，但现实是——数据库泄露事件每天都在发生。

我曾经参与过一个事故复盘：某IoT平台数据库被拖库，里面存的是明文密码。结果不仅是MQTT Broker被攻破，连用户的云账号、支付密码都被撞库成功。那场面，惨不忍睹。

正确的做法，是哈希加盐存储。说白了，就是：

不能存明文——这是底线，没有任何借口
不能只用简单哈希——MD5、SHA-1这些，彩虹表一查就破
必须加盐——每个密码配一个随机盐值，让彩虹表失效
必须用慢哈希算法——bcrypt、scrypt、Argon2，这些算法计算慢，能有效抵御暴力破解

来看一个具体的实现示例（Python + bcrypt）：

import bcrypt

# 注册时：生成盐值并哈希密码
def hash_password(plain_password):
    # 自动生成16字节随机盐值
    salt = bcrypt.gensalt(rounds=12)  # rounds=12，计算约250ms
    hashed = bcrypt.hashpw(plain_password.encode('utf-8'), salt)
    return hashed.decode('utf-8')

# 验证时：从数据库取出哈希值，比对
def verify_password(plain_password, stored_hash):
    return bcrypt.checkpw(
        plain_password.encode('utf-8'),
        stored_hash.encode('utf-8')
    )

# 使用示例
stored = hash_password("MySecureP@ss123")
print(stored)  # 输出类似：$2b$12$...（包含盐值和哈希值）

# 验证
result = verify_password("MySecureP@ss123", stored)
print(result)  # True

这里要注意几个关键点：

参数	建议值	说明
算法	bcrypt / Argon2id	Argon2id是2015年密码哈希竞赛冠军，推荐优先使用
盐值长度	≥16字节	足够抵抗预计算攻击
计算耗时	250ms~500ms	太慢影响用户体验，太快容易被暴力破解
盐值存储	与哈希值一起存储	bcrypt的输出本身就包含了盐值，无需单独存

警告：千万不要自己实现哈希算法！不要用MD5+SHA1拼接这种「土办法」。密码学领域，自己造轮子=给自己挖坑。用业界公认的库，比如Python的bcrypt、Go的golang.org/x/crypto、Java的jBCrypt。

3.3 传输加密的必要性：中间人攻击的噩梦

密码存得再安全，如果传输过程是明文的，那一切白搭。MQTT默认的TCP连接，数据是明文传输的。攻击者在同一网络里抓个包，用户名密码一览无余。

我记得有一次帮客户做渗透测试，在咖啡店用Wireshark抓包，不到5分钟就抓到一台智能灯控设备发送的MQTT CONNECT报文，用户名light_ctrl，密码light2023。然后我用这个凭证，直接控制了整栋楼的灯光系统。

所以，传输加密不是可选项，是必选项。具体怎么做？

必须启用TLS/SSL——MQTT over TLS，端口通常用8883
证书验证不能跳过——客户端必须验证服务端证书的有效性
使用强加密套件——禁用TLS 1.0/1.1，优先TLS 1.3，至少TLS 1.2
双向认证更安全——服务端也验证客户端证书，形成双重保障

来看一个MQTT客户端启用TLS的配置示例（Python + paho-mqtt）：

import paho.mqtt.client as mqtt
import ssl

client = mqtt.Client(client_id="secure_device_001")

# 配置TLS
client.tls_set(
    ca_certs="/etc/ssl/certs/ca-cert.pem",      # CA证书，用于验证服务端
    certfile="/etc/ssl/certs/client-cert.pem",   # 客户端证书（双向认证时用）
    keyfile="/etc/ssl/private/client-key.pem",   # 客户端私钥
    cert_reqs=ssl.CERT_REQUIRED,                 # 强制验证服务端证书
    tls_version=ssl.PROTOCOL_TLSv1_2,            # 指定TLS版本
    ciphers="ECDHE-ECDSA-AES128-GCM-SHA256"      # 指定加密套件
)

# 设置用户名密码（在TLS加密通道内传输）
client.username_pw_set("device_user", "SecureP@ss123")

# 连接Broker
client.connect("mqtt.example.com", 8883, 60)

关键点：用户名密码是在TLS握手完成后的加密通道内传输的。即使攻击者抓包，也只能看到加密后的乱码。但要注意，如果TLS配置不当（比如跳过证书验证），中间人攻击依然可以得逞。

这里我画了一张流程图，帮你理清整个认证加固的脉络：

这张图把三个环节串起来了。你会发现，每一层都在解决不同的问题：

密码策略——让密码本身难以被猜测或暴力破解
安全存储——即使数据库泄露，攻击者也拿不到原始密码
传输加密——防止密码在传输过程中被截获

三层缺一不可。你想想看，如果密码策略做得再好，但传输是明文的，那等于把密码写在明信片上寄出去。反过来，TLS再强，密码存的是明文，数据库一泄露全完蛋。

我的习惯：每次做MQTT安全方案，我都会先画这样一张三层防护图，然后逐层检查。哪一层没做到位，就补哪一层。别想着一步到位，但每一层都不能有致命漏洞。

最后说一个我曾经踩过的坑。有一次，我帮客户做MQTT Broker迁移，新Broker的TLS配置里忘了设置cert_reqs=ssl.CERT_REQUIRED，结果客户端没有验证服务端证书。虽然TLS连接建立成功了，但实际上是中间人攻击的「欢迎模式」。幸好是在测试环境发现的，要是上了生产，后果不堪设想。

所以，配置完TLS之后，一定要用openssl s_client或者Wireshark抓包验证一下，确保证书验证是生效的。别问我为什么知道要这么做——嗯，都是教训换来的。