3、身份认证机制：密码认证、生物特征认证、多因素认证、单点登录(SSO)
身份认证，说白了就是「你怎么证明你是你」。
在座舱系统里，这事比手机认证要复杂得多。你想想看，手机认证失败了顶多重启，座舱认证出问题，车可能就开不了。我参与过好几个座舱项目，每次身份认证模块都是被反复审查的环节。
3.1 密码认证：最基础，也最容易被攻破
密码认证是门槛最低的方式。但说实话，它也是安全风险最高的。
座舱系统里，密码认证通常用在首次激活、恢复出厂设置、或者进入工程模式时。我个人习惯把密码分为三类：
- 用户密码：车主设置的简单密码，用于日常解锁
- 管理员密码：4S店或维修人员使用，权限更高
- 工程密码：研发阶段使用，量产时必须禁用
正确的做法是使用哈希加盐存储。比如这样：
// 密码存储示例（伪代码）
String password = "user123";
String salt = generateRandomSalt(); // 生成随机盐值
String hash = SHA256(password + salt); // 哈希计算
storeToSecureStorage(hash, salt); // 分开存储为什么要加盐？因为不加盐的话，两个用户用相同密码，哈希值就一样。攻击者一看就知道。加盐之后，每个用户的哈希值都不同，彩虹表攻击就失效了。
3.2 生物特征认证：方便，但别太依赖
指纹、人脸、声纹，这些在手机上已经普及了。座舱系统里，生物特征认证最大的价值是「无感」——你坐进车里，系统就认出你了。
但这里有个坑：生物特征不是密码。密码可以改，指纹能改吗？不能。一旦生物特征数据泄露，那就是永久性的。
关键原则：生物特征只用于「本地验证」，绝不能上传云端。我见过一个方案，把指纹模板上传到后台做比对，我当时就否决了——万一服务器被攻破，所有车主的指纹都暴露了。
座舱系统里，生物特征认证的典型流程是这样的：
- 传感器采集生物特征（指纹图像、人脸照片等）
- 特征提取算法生成特征模板（不是原始图像）
- 模板加密后存储在安全芯片（SE/TEE）中
- 每次验证时，在安全环境中进行比对
- 比对结果只返回「通过/不通过」，不返回原始数据
我曾经遇到过一个问题：某款车的指纹识别在冬天经常失败。排查后发现，用户手指干燥导致电容传感器识别率下降。后来我们加了一个「干燥模式」，先喷点静电再识别。嗯，这种细节只有实际用过才知道。
3.3 多因素认证：安全与体验的平衡
多因素认证（MFA）就是「不只靠一种方式验证」。常见的组合有：
- 密码 + 指纹：最常见，适合日常使用
- 卡片 + 人脸：适合共享车辆或租赁场景
- 手机蓝牙 + 密码：适合代客泊车或临时授权
为什么需要多因素？因为单一因素总有漏洞。密码可能被偷看，指纹可能被复制，蓝牙可能被中继攻击。但两个因素同时被攻破的概率就低多了。
💡 我的建议： 座舱系统里，至少要有两个认证因素。一个是你知道的（密码），一个是你拥有的（手机/卡片），或者一个是你本身的（指纹/人脸）。这叫「双因素认证」。
但要注意，多因素认证不能影响用户体验。你想想看，每次上车都要输密码、刷指纹、再等短信验证码，谁受得了？所以实际项目中，我们通常只在敏感操作时才启用多因素认证，比如：
| 操作类型 | 认证要求 | 示例 |
|---|---|---|
| 日常解锁 | 单因素（蓝牙/指纹） | 靠近车门自动解锁 |
| 启动车辆 | 单因素（钥匙/手机） | 踩刹车启动 |
| 修改安全设置 | 双因素（密码+指纹） | 更改紧急联系人 |
| 恢复出厂设置 | 双因素（密码+卡片） | 清除所有用户数据 |
3.4 单点登录(SSO)：打通座舱生态的关键
单点登录，说白了就是「一次登录，到处可用」。在座舱系统里，SSO的价值特别明显——你登录了车机账号，音乐、导航、语音、支付这些服务就都自动登录了。
但座舱系统的SSO和Web端的SSO有很大不同：
- 离线场景：车可能没网，SSO必须支持离线令牌
- 多用户切换：家庭用车，不同家庭成员切换账号
- 安全等级差异：导航登录和支付登录的安全要求不同
我参与的一个项目中，SSO的实现方案是这样的：
// SSO令牌结构（简化版）
{
"user_id": "u12345",
"token_type": "refresh", // 或 "access"
"expires_at": 1700000000,
"scopes": ["nav", "music", "payment"],
"offline_valid": true, // 是否支持离线使用
"device_id": "car_vin_123"
}这里有个关键点：离线令牌的有效期要严格控制。我见过一个案例，某厂商的离线令牌有效期设为30天，结果车被偷后，小偷用这个令牌用了整整一个月。后来我们改成了：离线令牌最多7天有效，且每次启动车辆时尝试联网刷新。
⚠️ 避坑指南： 我曾经在SSO实现中犯过一个错误——把主账号的权限直接给了所有子服务。结果音乐服务的一个漏洞导致攻击者拿到了支付权限。正确的做法是「最小权限原则」：每个服务只拿到它需要的权限，不要给全部。
3.5 四种认证机制的对比与选择
最后，我整理了一个对比表，方便你根据场景选择：
| 认证方式 | 安全性 | 用户体验 | 实现成本 | 适用场景 |
|---|---|---|---|---|
| 密码认证 | 低 | 中 | 低 | 首次激活、工程模式 |
| 生物特征 | 中 | 高 | 高 | 日常解锁、启动 |
| 多因素认证 | 高 | 低 | 中 | 敏感操作、支付 |
| 单点登录 | 中 | 高 | 高 | 生态服务、多账号 |
记住一句话：没有完美的认证方式，只有适合场景的方案。座舱系统里，安全性和用户体验永远在博弈。我的经验是：日常操作尽量无感，敏感操作必须严格。这样用户不会觉得烦，安全底线也守住了。
嗯，身份认证这块就讲到这里。下一章我们聊聊授权机制——认证通过之后，你能干什么、不能干什么，那才是真正的权限管理核心。