【前端】前后端联合加密方案：让用户的数据安全不再依赖于服务商的信用

1 从源头说起

传统web应用中，往往采取的是发送明文密码，后端再使用Bcrypt加密密码，存储到数据库的方案。至于用户的其他数据，则不加密，直接存储到数据库中。最后再使用JWT与用户保持通信。

两个弊端

• 用户的密码是否泄漏依赖于服务商的自觉及数据库的安全性。
• 用户的数据是否泄漏依赖于服务商数据库的安全性。

本应用，最重要的假设是，服务商是完全不可信任的，即便承诺了会对数据进行脱敏处理，普通用户也永远无法确认他们真的这么做了。

因此

• 不能将明文密码直接发送至服务商后端，避免服务商使用打印日志或其他手段轻松获取用户的明文密码。
• 不能将用户希望加密的数据发送至服务商后端，避免服务商根据用户的其他数据分析用户的习惯。

既然无法仅依靠服务商的后端加密，那无疑就要在前端再加一层加密。

然而，在前端进行加密有无必要一直被广泛讨论，很大程度上就是因为前端无论如何加密，最终都是收效甚微的。

• 如果使用硬编码密钥（EBC模式及固定偏移量的CBC模式下的AES256等）的加密方案，无疑会导致整个应用所有使用简单密码的用户都遭受彩虹表攻击的风险。
• 如果使用随机（随机偏移量的CBC模式下的AES256、Bcrypt等）的加密方案，则无法确保每次生成的发送至后端的值都是相同的，导致无法验证的问题。

综上，采用前后端联合+后端单独双层加密方案。

 1.注册时，用户向服务商申请两个随机盐值（将被持久化到服务商数据库中），分别是“登录盐值”与“加密盐值”。

 2.注册时，在前端使用Bcrypt及“登录盐值”散列用户的密码，得到“登录散列”，将登录散列发送并持久化至服务商数据库。

 3.登录时，用户从服务商数据库中取出登录盐值，在前端重新计算登录散列，再次将登录散列发送至服务商，实现身份验证。

 4.登录成功时，用户从服务商数据库中取得加密盐值，在前端使用Bcrypt及“加密盐值”散列用户的密码，得到“加密散列”。随后在前端内存中销毁用户的原始密码。

 5.用户每次发送待加密数据时，在前端以加密散列为密钥，待加密数据为明文进行加密，发送至服务商。

最终效果：用户的数据安全不再依赖于服务商的信用

• 现在，即便服务商持有随机盐值与登录散列，也只能使用费时费力的暴力破解方式尝试获取用户原始密码。
• 即便服务商持有随机盐值、登录散列与加密后数据，也无法解密用户的数据。只能先暴力破解用户的原始密码，再根据原始密码和加密盐值算出加密散列，再解密用户存储在数据库里的的加密数据。
• 服务商尚且如此，想要破解用户数据的黑客更是难上加难，即便通过xss等攻击手段获取到了存留在用户浏览器中的加密散列。除了暴力破解以外也无法得知用户原始密码进而窃取用户的数据管理权限。只要用户的密码强度不是极弱，完全来得及备份转移数据。·

2 前端登录散列详解

1. 加密方式：Bcrypt，盐值为后端返回的登录盐值，明文为原始密码。
2. 为什么不使用AES256：AES256是可逆的，持有密钥和密文的服务商将可以直接破解用户原始密码。

3 后端登录散列的散列详解

1. 加密方式：Bcrypt，盐值记录在数据库，明文为登录散列。
2. 意义：再套一层，大幅增加黑客的暴力破解成本。

4 前端加密散列详解

1. 加密方式：Bcrypt，盐值为后端返回的加密盐值，明文为原始密码。
2. 为什么不使用AES256：也可以使用AES，反正黑客最多拿到密文，服务商则只有密钥，都无法破解出原始密码，这里使用Bcrypt只是稍微增加点保障。

5 前端数据加密详解

1. 加密方式：AES256，密钥为加密散列，明文为用户指定的待加密数据，进行AES256 固定偏移量的CBC模式加密。
2. 为什么不使用Bcrypt：Bcrypt是不可逆的，无法还原数据。
3. 为什么不使用EBC：可能泄露数据模式。
4. 为什么不使用随机偏移量的CBC：只是会在不同数据拥有相同第一个数据块时该数据块数据模式泄露，必要性不大，从简处理。

6 加密数据绝对安全的代价

1. 作为服务提供者的本人也无法以除暴力破解外的方式获取用户的原始密码，这意味着一旦用户忘记密码，所有用户指定要加密的数据都无法恢复。
2. 用户一旦修改密码，将会导致在使用旧密码时创建的加密数据无法被前端解析。
3. 为了减轻前两个问题的影响，可以在前端设计一个导出导入数据的功能，允许用户在修改密码时简单地转移数据。