数据安全5A之身份认证

本博客地址：https://security.blog.csdn.net/article/details/120543745

一、引子

在专栏开篇作中我有提到数据安全架构中的5A概念，5A概念中的其中一个A是身份认证，因此，本篇我们来聊聊身份认证相关的东西。

我们先重复一下“基于身份的信任思维”：不信任企业内部和外部的任何人、任何系统，所有请求都需基于身份认证和授权，执行以身份为中心的访问控制和资产保护。

通常的，身份认证包括：
● 对人的身份认证。
● 后台间身份认证。
● 对设备的身份认证。

二、如何进行身份认证

在企业的实践中，我们一定要记得，不要在每个业务中自行建立身份认证系统，业务系统应尽可能使用统一的SSO（单点登录系统）。所谓单点登录就是不管员工或用户访问哪个业务，都只有一个身份认证入口，并在这个入口处完成身份认证动作。比如我们访问腾讯的视频、游戏等多个业务时，可以使用同一个登录入口、同一套账号体系。

单点登录系统作为企业统一建设并提供认证服务的基础设施，其好处多多，包括：

● 避免各业务自行重复建设，在很大程度上简化了业务的工作量。
● 可以统一强化对用户隐私的保护，避免用户隐私（口令、双因子保护口令、生物特征等）因分散存储、保护不当而泄露。
● 内部SSO系统，可与HR系统关联，离职销户，消除员工离职后的风险。

最典型的身份认证场景是用户输入自己的用户名和口令，SSO单点登录系统验证无误后，返回一个认证通过的Ticket，在后面的访问中，有如下常见的Ticket使用方式：

● 会话机制：用户带上这个Ticket访问应用系统（但只使用一次），应用系统验证Ticket无误后，跟用户建立自己的会话，在这个会话的有效期内，用户和应用系统不再访问SSO（适用于To B业务，访问的数据不一定是访问者自己的数据）。
● 全程Ticket机制：用户全程带上这个Ticket，可以访问自己权限范围内的数据（适用于To C业务，即访问的资源都是用户自己的资源）。
● 持续的消息认证机制：每次请求都执行身份认证。

2.1、会话机制

使用会话机制的身份认证原理一般是：持SSO颁发的Ticket访问应用系统，应用系统验证Ticket无误之后，会建立会话机制，通过Cookie字段自动传递，存在有效期限制，超过设定的有效期会失效。在会话有效期内，用户不需要再访问SSO，应用系统也不再去验证该用户的Ticket。

这里科普一下Cookie的安全：

Cookie用于身份等敏感信息的传递，所以也需要额外的保护。典型的做法是为其启用HttpOnly和Secure属性。启用了HttpOnly属性之后，可以防止其被JavaScript读取到，使用document.cookie无法获取到其内容；启用Secure属性之后，则只能通过HTTPS传递。在Cookie中尽量不要存储敏感的数据，不得不存储的时候，建议考虑加密措施。

2.2、持续的消息认证机制

在通常的业务场景中，都是先认证，然后在认证通过的会话有效期内和授权范围内访问业务。但在某些场景中，如手机APP访问后台服务器，这种一次性认证并不一定是最佳的，为了保证用户体验，一次性认证后的会话有效期需要设置得特别长，这就带来了新的风险：如果会话凭据（Cookie或Session）被窃取，则用户的身份就会被盗用，给用户带来各种损失。

鉴于此，我们可以采用持续的消息认证机制（也可以和会话机制配合使用），每次请求都执行身份认证。

持续的消息认证可以采用密码学上的认证加密机制，一般情况下，如果不知道选用什么模式，那就选GCM模式，它在多数场景下适用，除非在特定要求的情况下，再使用特定的加密模式。

科普：GCM加密模式

GCM是在加密算法中采用的一种计数器模式，带有GMAC消息认证码。AES的GCM模式属于AEAD算法，同时实现了加密、认证和完整性保障功能。在各种加密模式中，除了GCM外，还有我们常听到的ECB、CBC、CFB、OFB、CTR等等。

2.3、不同应用的登录状态与超时管理

用户在成功登录一次SSO后，如果此时可以直接访问所有使用该SSO认证的应用，是存在风险的。因为在这些应用中，有些应用是保密性比较高的，当员工认证通过的Ticket被窃取，身份就会被盗用；还有一个更简单的场景是，当员工离开座位而没有锁定屏幕时，可能会被路过的同事操作电脑，访问一些敏感数据。

为了解决这个问题，可以使用前面提到的基于每个应用自身的会话机制。每个应用可以设置自己的会话超时时间（比如30分钟），在会话有效期内如果存在请求，则会话超时会重新计算（也就是顺延）。在会话超时后，应用系统会通过重定向跳转到SSO，重新进行认证，这样在大部分工作时间中，员工本地浏览器是没有高保密系统的会话凭据的。

如此的话，员工日常登录各应用系统就会是这样的场景：

● 登录大多数办公应用，很少需要输入口令进行身份认证，登录的频次取决于SSO设定的默认有效时间；
● 登录敏感度比较高的应用，一般需要输入口令进行身份认证，并且会话很快就失效。

三、口令的保护

如果没有单点登录系统怎么办呢？此时就需要通过其他方式来保障认证的安全性了，例如：

● 用户的口令一定不能明文存储。
● 用户的口令在服务器侧一定需要执行加盐散列操作。
● 用户身份认证环节一定要使用HTTPS传输。
● 建议用户侧不要直接发送明文的口令（即使采用了HTTPS传输加密）。

用户的口令属于用户的个人隐私，如保护不当，会与法律或监管要求、合规要求冲突。用户的口令泄露之后，会给企业的声誉带来严重影响，如被坏人利用，则可能给用户个人带来资金安全等损失；更有甚者，由于用户往往在不同的网站使用相同的口令，黑客可以使用这些泄露的口令，进行撞库，造成损失范围的进一步扩大。因此，对用户口令，需要执行特别的保护措施。

各种口令的存储方式及风险：

服务器存储方式	问题或风险
明文存储或编码存储	数据库文件被拖走则大量用户口令泄露，因此不能使用
单项散列	数据库文件被拖走则基于彩虹表大部分复杂度不高的口令会泄露，不推荐单独使用
加盐单项散列	如果盐值随数据库文件被拖走，由于彩虹表失效，需要暴力破解，延缓了破解时间，黑客一般只能破解部分弱口令
慢速加盐散列	比较安全，暴力破解的时间成本大幅增加，但宝贵的服务器资源浪费在延时上面，会导致并发服务能力下降，不宜大量在服务侧使用

以上，一般情况下使用的是加盐单项散列，加盐单项散列在安全与效率做到了较好的权衡，但仍存在暴力破解的风险。为了解决这个问题，我们可以考虑将慢速加盐散列做进来，不过是做到前端用户侧去，这样既能充分利用服务器资源，也能让慢速HASH起到延时防撞库的作用，这种百毫秒级别的延时，对用户的影响几乎是可以忽略不计的。

另外，还有弱密码问题，这个属于最基础但危害最大的点，具体就不展开讨论了。

四、生物认证数据的保护

目前业界主要的认证方式，除了口令或动态口令，还有生物认证，比如指纹考勤、人脸识别门禁等。

生物特征，包括指纹、声纹、虹膜、面部特征等，属于用户的个人隐私，如果处理或保护不当，会与法律法规或监管要求、合规要求冲突。与口令相比，这些隐私需要更强的保护措施。

如果上传用户的生物识别图像（指纹图像等），无论是否加密，图像都有可能泄露（例如被收买的有权限的员工）；另外由于生物识别图像不能修改，一旦泄露，将造成不可挽回的损失。因此，上传生物识别图像是万万不可的。

那么该如何处置生物特征数据呢？可行的方法只有上传经过处理的生物特征值，而不是原始图像。如果是用于手机等智能终端的身份认证，则建议指纹比对仅在硬件层级完成，指纹数据不出手机。

因为按GDPR相关条款，原则上禁止处理用户的生物识别数据等特殊类型的个人数据，如果一定需要处理，则需要合法的依据，如经过用户明示同意（此条最为重要）、法定义务等。由于GDPR具有长臂管辖权，即使你的企业不在欧洲，但只要涉及处理欧盟公民的个人数据，就在GDPR的管辖范围内。

生物认证的关键技术点在于：

● 受制于温度、湿度、采集位置、时间、环境的变化，每次采集的生物特征其实都是不一样的。
● 需要通过算法来比对，以判断特征值1和特征值2是否为同一个人。

因此，口令的保护方法并不能用于保护生物特征，即不能使用单向散列保护保护生物特征。

为了保护这些隐私数据，可以考虑通过如下方式：

● 通过对称加密（AES 128或以上）存储用于比对的生物特征。
● 认证过程需要携带及验证时间戳，防止重放攻击。

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

五、后台应用身份认证

后台应用不同于前台应用，因为它不是用户身份认证的场景，一般情况下，常见的后台应用的认证方式有以下5种：

● 基于用户Ticket的后台身份认证（重点）。
● 基于AppKey的后台身份认证。
● 基于非对称加密算法的后台身份认证。
● 基于HMAC的后台身份认证。
● 基于AES-GCM共享密钥的后台身份认证（重点）。

当然，实际中还有其他很多种方式，也就不具体展开讨论了。

5.1、基于用户Ticket的后台身份认证

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

用户在通过SSO系统认证，获得SSO颁发的Ticket首次访问应用系统时，应用系统在验证Ticket无误之后，直接将其纳入会话缓存起来（即Ticket当session）。这样后续每次请求都会带上Ticket，后台之间请求数据的时候也带上这个Ticket，也就是全程携带Ticket。

不过通常来说，这只适用于To C业务，消费者访问自己特定的资源，比如用户自己的网上相册、购物记录等场景。

基于用户Ticket的后台身份认证的过程如下：

1）系统A在请求后端系统B的数据时，把用户在SSO认证时通过的Ticket同时带上。
2）后端系统B收到Ticket之后，会去SSO系统校验用户身份。
3）SSO校验通过之后，返回用户身份信息。
4）后端系统B返回用户特定的数据，Ticket对应的身份将临时缓存起来以便短期内继续使用。

由于这种方式访问的数据范围仅限用户个人创建的数据，安全性比较高，推荐使用。

5.2、基于AppKey的后台身份认证

这种方式使用AppID和AppKey进行系统间的认证，其中：

AppID相当于用户身份认证中的用户名。
AppKey相当于用户身份认证中的口令。

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

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

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

非对称加密不能用于大量消息传输或需要频繁对消息进行认证的场景，主要用于如下场景：

● 一次性认证场景（只在会话开始认证一次，在会话有效期内，不再重新认证），比如程序员在向Github提交代码时，往往使用证书认证机制（私钥留在本地，公钥配置在Github账号中）。
● 协商对称加密密钥场景（即真正对大量数据加密还是使用对称加密算法）。

5.4、基于HMAC的后台身份认证

HMAC是加密和HASH算法的结合，可以视为HASH算法的安全加强版。

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

利用HMAC的特点，可用于内网后台间身份验证。为了防止重放，可以在消息体中加入时间戳等信息。

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

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

六、双因子认证

双因子认证通常是SSO团队需要考虑的事情。双因子认证就是在原来的口令基础上添加额外的安全机制。这些额外的安全机制包括但不限于如下形式：

● 手机短信验证码。
● TOTP（动态口令），通常每30秒或60秒生成一个变化的6位数字。
● U2F（通用双因子身份认证，可以理解为比U盾更高级的硬件设备）。

七、扫码认证

如果一个业务既可以从电脑上访问，也支持对应的手机APP访问，就可以使用手机APP的扫码登录功能。如果某个业务支持第三方认证，且第三方认证支持扫码登录，同样也可以使用第三方的手机APP扫码登录。