读数据安全架构设计与实践04身份认证(下)

1. 口令面临的风险及保护

1.1. 不恰当的口令存储方式及数据库被拖库，如明文存储、弱散列算法（如MD5）且未加盐

1.2. 用户在不同网站使用同一口令所引起的撞库

1.3. 登录模块针对撞库的控制措施缺失或不足

1.4. 口令的保护

• 1.4.1. 用户的口令属于用户的个人隐私

• 1.4.2. 户的口令一定不能明文存储

• 1.4.3. 用户的口令在服务器侧一定需要执行加盐散列操作

• 1.4.4. 用户身份认证环节一定要使用HTTPS传输

• 1.4.5. 建议用户侧不要直接发送明文的口令（即使采用了HTTPS传输加密）​

1.5. 彩虹表

• 1.5.1. 即预先计算的HASH表，并对HASH值进行索引，可通过HASH值快速查询到明文口令

1.6. 口令强度

• 1.6.1. 太简单很容易被猜出或被暴力破解的口令

• 1.6.2. 已经泄露的口令

• 1.6.2.1. 对用户而言，历次数据泄露事件中泄露的用户口令，可用于撞库

• 1.6.2.2. 对于后台服务器而言，包括员工私自开源（或黑客入侵后翻找文件）​、配置文件中泄露的口令，且这些口令可能还用在其他服务器上）

• 1.6.3. 建议的口令强度标准是：14位以上，且包含大写字母、小写字母、数字、特殊符号

• 1.6.4. 密码短语，就是将几个单词拼接在一起，并替换部分字母

• 1.6.5. 诗词助记密码

2. 指纹、声纹、虹膜、面部识别的数据保护

2.1. 生物认证，使用范围不断扩大，比如指纹考勤、出入境自助刷指纹通关、人脸识别门禁等等

2.2. 生物特征，包括指纹、声纹、虹膜、面部特征等，属于用户的个人隐私，如果处理或保护不当，会与法律法规或监管要求、合规要求冲突

2.3. 与口令相比，这些隐私需要更强的保护措施

2.4. 如果上传用户的生物识别图像（指纹图像等）​，则无论是否加密，图像都有可能泄露​；且由于生物识别图像不能修改，一旦泄露，将造成不可挽回的损失

• 2.4.1. 可行的方法只有上传经过处理的生物特征值，而不是原始图像

• 2.4.2. 建议指纹比对仅在硬件层级完成，指纹数据不出手机

2.5. 按GDPR相关条款，原则上禁止处理用户的生物识别数据等特殊类型的个人数据，如果一定需要处理，则需要合法的依据，如经过用户明示同意（此条最为重要）​、法定义务等

• 2.5.1. 由于GDPR具有长臂管辖权，即使你的企业不在欧洲，但只要涉及处理欧盟公民的个人数据，就在GDPR的管辖范围内

2.6. 生物认证的关键技术点

• 2.6.1. 受制于温度、湿度、采集位置、时间、环境的变化，每次采集的生物特征其实都是不一样的

• 2.6.2. 需要通过算法来比对，以判断特征值1和特征值2是否为同一个人

• 2.6.3. 口令的保护方法并不能用于保护生物特征，即不能使用单向散列保护保护生物特征

• 2.6.4. 通过对称加密（AES 128或以上）存储用于比对的生物特征

• 2.6.5. 认证过程需要携带及验证时间戳（timestamp）​，防止重放攻击（黑客通过截获的生物特征伪造请求）​

• 2.6.6. 如果不需要上传生物特征也能解决认证问题时，就不要上传，比如智能终端（如手机）上的指纹认证

3. 单向散列算法

3.1. 业界使用最多的单向散列算法，就包括MD5和SHA-1，主要用于文件完整性检查、证书签名完整性、口令保护等领域

3.2. SHA-2：这是一个合集，包括SHA-224、SHA-256、SHA-384、SHA-512，推荐其中的SHA-256或SHA-512

3.3. SHA-3，第三代安全散列算法

3.4. 慢速加盐散列

• 3.4.1. 慢速加盐散列，可视为将加盐单向散列的动作重复很多次，常见算法包括bcrypt、scrypt、PBKDF2等，通过延缓时间（百毫秒级）来提高暴力破解难度

• 3.4.2. 将慢速加盐散列做进来，不过是做到前端用户侧去，这样既能充分利用服务器资源，也能让慢速HASH起到延时防撞库的作用

• 3.4.3. 前端慢速加盐散列

• 3.4.4. 后端再执行一次SHA256加盐散列，后端盐值是在创建时随机生成的，并写入数据库，在修改口令时会重新生成新的盐值

• 3.4.5. 慢速加盐散列措施是自动化工具绕不过去的一道坎，工具在提交之前，也必须基于密码字典执行同样的慢速加盐散列动作，在拖延时间方面可以起到很好的作用，直至令攻击者耗不起，从而放弃尝试

• 3.4.6. 如果执行百毫秒级（通常可采用300～500毫秒）的慢速加盐散列，则针对非特定用户的自动化工具就失去了意义

3.5. 目前还没有找到给定短报文的MD5/SHA-1碰撞方法，哪怕是最简单的报文“123456”​

3.6. 所有单向散列的目的都是寻求在实践中难以碰撞，而不是理论上绝对安全，因为对于所有输出长度固定的单向散列算法，只要输入样本数超过输出所能表达的全部变化数即可，以SHA-512为例，只要样本数大于2512（2的512次方）就能制造出碰撞

3.7. 如果你的业务不涉及测评、认证、监管要求，暂时还可以维持现状，但一旦业界找到了给定字符串的碰撞方法，那就必须升级了

3.8. 如果你的业务有测评或认证需求，使用弱散列算法作为主保护措施会被视为风险项，越早改进越好

• 3.8.1. 由于散列是不可逆的，我们无法直接对现有的散列值进行复原，这时候可以把当前已有的加盐散列算法作为前置的辅助措施，新增一个字段作为新的加盐散列结果，使用强散列算法（如SHA-256）对以前的结果再执行一次加盐散列，验证无误后删除原来的散列值即可

4. 后台身份认证

4.1. 基于用户Ticket的后台身份认证

• 4.1.1. 基于用户Ticket的后台身份认证，就是在访问资源的过程中，后台系统也基于用户身份进行认证

4.2. 基于AppKey的后台身份认证

• 4.2.1. AppID相当于用户身份认证中的用户名

• 4.2.2. AppKey相当于用户身份认证中的口令

• 4.2.3. AppID和AppKey一旦泄露，则数据安全将得不到保障，仅适合对安全性要求一般的场景

• 4.2.4. 在认证过程中，建议使用POST方式传递AppID和AppKey

• 4.2.5. 有的业务在此基础上，使用了AppID+AppKey+AppSecret三个要素，这时，AppKey可以视为会员卡（或不同的权限标识）​，而AppSecret可以视为口令（或密钥）​

4.3. 基于非对称加密算法的后台身份认证

• 4.3.1. 公钥公开，私钥保密

• 4.3.2. 私钥加密的数据，只有对应的公钥能够解开

• 4.3.3. 公钥加密的数据，只有对应的私钥能够解开

• 4.3.4. 非对称加密算法的加密速度很慢，只能用于少量的加密运算

• 4.3.5. 私钥需要特别的保护，如果私钥的存放有可能泄露，则身份可能会被盗用

• 4.3.6. 一次性认证场景

• 4.3.6.1. 只在会话开始认证一次，在会话有效期内，不再重新认证

• 4.3.7. 协商对称加密密钥场景（即真正对大量数据加密还是使用对称加密算法）​

4.4. 基于HMAC的后台身份认证

• 4.4.1. HMAC的全称是Hash-based Message Authentication Code（散列运算消息认证码）​，是加密和HASH算法的结合，可以视为HASH算法的安全加强版

• 4.4.2. HMAC是不可逆的加密摘要，接收方可利用同时收到的消息明文msg，以及预先就知道的密钥key（可通过会话同步给客户端）​，执行同样的HMAC-SHA256运算，将得到的摘要HMAC2与收到的摘要HMAC1进行比较，相等则确认发送者身份跟声称的身份一致且消息未被篡改

• 4.4.3. HMAC的用途

• 4.4.3.1. 身份认证：确定消息是谁发的（对约定的消息进行运算，比如请求的参数以及当前时间戳）​

• 4.4.3.2. 完整性保障：确定消息没有被修改（HMAC运算结果不包含消息内容，通常和明文消息一起发送，不能保障消息的保密性）​

• 4.4.4. 利用HMAC的特点，可用于内网后台间身份验证

• 4.4.4.1. 为了防止重放，可以在消息体中加入时间戳等信息

• 4.4.5. 大多数场景，要么是请求资源，要么是传递消息，这些场景均需要发送具体的消息来表明自己的目的

• 4.4.6. 少量场景，比如应用A只需要向应用B发送心跳，这时候可以把时间戳当作消息执行HMAC运算

4.5. 基于AES-GCM共享密钥的后台身份认证

• 4.5.1. HMAC消息认证机制并没有对消息进行加密，如果需要确保消息的保密传输，就可以考虑使用AES-GCM

5. 双因子认证

5.1. 手机短信验证码

• 5.1.1. 坏人可以利用社会工程学的手段，骗取用户的短信验证码，或者利用手机木马窃取短信验证码

• 5.1.2. 过去曾经出现过利用运营商的自助补卡功能，盗取用户手机号码的情况

5.2. TOTP

• 5.2.1. Time-based One-Time Password，动态口令

• 5.2.2. 基于RFC 6238，每间隔指定的时间（常用的有30秒、60秒）生成一个与时间相关的数字（通常为6位）​，可通过硬件或软件（如手机APP）等载体实现

• 5.2.3. 动态口令和静态口令混合在一起使用时，已经是动态变化的口令，用户的静态口令就没有必要定期修改了，大大提升了用户体验

• 5.2.4. TOTP的安全性相对就比较高了，多用于企业内部员工的SSO

• 5.2.5. 动态口令也只适用于内网员工使用，如果用于向互联网发布的业务，仍存在被钓鱼网站窃取身份的可能性

5.3. U2F

• 5.3.1. Universal 2nd Factor，通用双因子身份认证​

• 5.3.2. Google在实施零信任网络架构后，员工也像普通用户一样，使用外网地址访问公司业务，为了避免员工被钓鱼攻击，*将原来的TOTP更换成了U2F

• 5.3.3. 由Google和Yubico共同推出的开放认证标准，使用USB设备或NFC（Near Field Communication，近场通信）设备执行进一步的验证

• 5.3.4. 用户携带一个支持U2F的钥匙扣设备，即可访问所有支持此协议的应用

• 5.3.5. U2F和传统的U盾都是采用非对称加密技术，但是U2F是通用标准，可以在多个应用中使用，而U盾通常只能用于一个业务

• 5.3.6. 与U盾相比，U2F在安全性、用户体验上均有质的提升

6. 扫码认证

6.1. 本质上是一种信任传递机制

6.2. 如果一个业务既可以从电脑上访问，也支持对应的手机APP访问，可以使用手机APP的扫码登录功能

6.3. 如果某个业务支持第三方认证，且第三方认证支持扫码登录，同样也可以使用第三方的手机APP扫码登录