3. 合规标准与框架：GDPR、CCPA、PCI-DSS、ISO 27001、NIST SP 800-63B 对口令的要求
做智能设备安全，最头疼的往往不是技术本身，而是「合规」。你想想看，一个产品要卖到欧洲、美国、加州，每个地方的法律法规都不一样。我早年做一款智能门锁，就因为口令存储方式没满足 GDPR 要求，被勒令下架整改。嗯，从那以后，我养成了一个习惯：设计口令策略之前，先把合规清单拉出来过一遍。
这一章，我们就来拆解五个最常碰到的合规标准。它们对口令的要求，说白了就是「你该怎么存、怎么传、怎么设、怎么管」。
3.1 GDPR：用户说了算
GDPR（通用数据保护条例）是欧盟的法规。它不直接规定「口令必须12位」，但它要求你保护个人数据。口令，毫无疑问属于个人数据。
我个人的理解是，GDPR 的核心就一句话：用户的数据，用户做主。落实到口令上，有几点必须注意：
- 知情同意： 你不能偷偷收集口令。注册时得明确告知用户，口令用来干嘛、存多久、谁有权访问。
- 数据最小化： 别问用户要多余的密码提示问题。比如「你小学名字」这种，能不要就不要。
- 存储安全： 口令必须加盐哈希存储。明文存储？那是找死。我在项目里见过有人用 MD5 直接存，被审计直接打回。
- 泄露通知： 如果口令库被拖库，72 小时内必须通知用户和监管机构。
3.2 CCPA：加州的「知情权」
CCPA（加州消费者隐私法案）和 GDPR 很像，但更侧重「消费者知情权」。说白了，用户有权知道企业收集了哪些个人信息，包括口令。
对口令设计的影响：
- 用户有权要求你删除他的账号和口令。你不能说「技术原因删不了」。
- 用户有权要求你提供一份他所有个人数据的副本，包括口令的哈希值（当然，你不能把明文给他）。
- 如果因为口令泄露导致用户损失，企业要承担赔偿责任。
嗯，这里要注意：CCPA 对「出售个人数据」的定义很宽泛。如果你把用户口令哈希值传给第三方分析服务，可能也算「出售」。我建议你在设计阶段就把数据流图画清楚。
3.3 PCI-DSS：支付口令的硬杠杠
如果你的智能设备涉及支付功能（比如智能 POS 机、支付手环），那 PCI-DSS 就是绕不过去的坎。它对口令的要求非常具体，几乎是手把手教你做。
| PCI-DSS 要求 | 具体内容 | 我的解读 |
|---|---|---|
| 要求 8.2.1 | 口令长度至少 7 位，包含字母和数字 | 这是最低要求。我建议至少 12 位，别卡着底线做设计 |
| 要求 8.2.3 | 每 90 天更换一次口令 | 智能设备上这个很烦人。可以考虑用生物识别替代定期更换 |
| 要求 8.2.4 | 不允许重复使用最近 4 次的口令 | 记住历史口令列表，别让用户来回换 |
| 要求 8.2.5 | 连续 6 次登录失败后锁定账号 | 锁定时间至少 30 分钟，或者需要管理员解锁 |
| 要求 8.2.6 | 会话超时后需要重新登录 | 智能设备建议 15 分钟无操作自动锁屏 |
3.4 ISO 27001：管理体系的口令要求
ISO 27001 不是技术标准，而是管理标准。它不告诉你「口令多长」，而是要求你「有制度」。说白了，你得证明你有一套流程来管理口令安全。
具体到口令策略，ISO 27001 的 Annex A 控制项里有几条：
- A.9.2.1 用户注册与注销： 每个用户必须有唯一 ID，不能共享账号。智能设备上，每个管理员都应该有自己的账号。
- A.9.2.4 特权访问管理： 超级管理员口令要更严格。我建议特权口令长度至少 16 位，且必须使用硬件密钥或 MFA。
- A.9.3.1 口令管理系统： 要有口令管理软件或流程。不能把口令写在便利贴上贴在设备上——别笑，我在工厂里真见过。
- A.9.4.3 口令使用策略： 要求用户定期更换口令，且不能使用弱口令。
3.5 NIST SP 800-63B：最务实的技术指南
终于说到 NIST 了。我个人最喜欢这个标准，因为它非常务实。NIST SP 800-63B 是《数字身份指南》的一部分，专门讲口令验证。它推翻了很多传统认知。
几个关键点：
- 长度比复杂度重要： NIST 建议口令至少 8 位，但推荐 12-16 位。它不强制要求大小写+数字+特殊字符。为什么？因为研究表明，长口令比复杂口令更难被破解。
- 不要定期更换： 除非有泄露证据，否则不要强迫用户每 90 天换一次口令。这会导致用户用「Password1!」「Password2!」这种规律性口令。
- 检查弱口令： 必须对用户设置的口令进行黑名单检查。常见弱口令（123456、password、qwerty）直接拒绝。
- 支持粘贴： 允许用户粘贴口令。这方便使用口令管理器。
- 失败锁定： 连续失败次数不超过 100 次（对，100 次，不是 6 次）。但锁定时间要指数级增长。
3.6 如何把这些标准落地到智能设备上？
理论说完了，来点实际的。我总结了一个「合规口令策略检查清单」，每次设计新设备时都会过一遍：
- 存储： 使用 bcrypt/Argon2 加盐哈希。不要用 SHA-1、MD5。
- 传输： 必须走 TLS 1.2+。口令绝不能在 URL 参数里传递。
- 复杂度： 至少 8 位，推荐 12 位。检查常见弱口令。
- 锁定： 连续失败 5-10 次后锁定 15 分钟。指数级增加锁定时间。
- 更换： 不强制定期更换，但支持用户主动更换。
- MFA： 支持多因素认证。智能设备上可以用指纹、人脸、或者一次性验证码。
- 日志： 记录所有登录尝试（成功和失败），保留至少 6 个月。
- 通知： 用户登录异常时（新设备、新地点）发送告警。