客户端明码加密有必要吗 一个有争议的话题

和小同伴们探讨一个有争议的话题：

有的人感觉明码加密间接在服务端启动就可以了，没必要在客户端做；当然也有人感觉可以在客户端启动明码加密，降落主机的压力。

你要问松哥名目中是怎样做的，我会通知你咱们在客户端就对明码加密了。

为什么这么做呢？

我来和大家聊聊咱们是怎样思考的。

一、烫手山芋

首先咱们有一个共识，就是明文明码是一个烫手山芋，是一个定时炸弹，应该尽早处置。

把这样一个炸弹从前端运到后端再启动加密处置，仿佛并非一个好的方法。应该尽早对炸弹启动处置，而后再启动运输。

那么在客户端就对明码启动加密的目标是什么？防止明码在传输环节中暴露吗？

显然不是！

关于重放攻打来说，人家压根不 care 你能否在客户端加密明码，关于重放攻打来说，明码能否在客户端启动加密，疑问都不大。

什么是重放攻打？重放攻打（Replay Attack）是一种网络安保攻打，攻打者经过截获并从新发送之前捕捉的数据包，以成功对系统的欺诈或破坏。这种攻打通常出当初没有正确成功信息认证和完整性包全的系统中。普通来说，重放攻打有三个特点：

普通来说，处置重放攻打比拟有效并且省事的方法就是上 HTTPS。

客户端对明码启动加密的目标是为了防止明文明码在抵达后端之后被滥用。这是最关键的目标。

为了参与破解老本，在前端启动加密的时刻，可以经常使用慢 hash 函数。

二、什么是慢 hash

慢哈希函数（Slow Hash Function）是一种明码学上的哈希函数，它被设计成故意减慢处置速度，以参与破解的难度。

这种函数通罕用于明码存储、密钥派生和某些加密算法中，目标是提供额外的安保层，防止暴力破解攻打。

普通来说，慢哈希函数关键有上方一些特点：

经常出现的慢哈希函数关键有如下几种，这几种也是咱们在 Spring Security 中比拟经常出现的：

以 BCrypt 为例，假设咱们控制 BCrypt 的口头期间大略是 0.1 秒成功一次性哈希计算的话，依照 1 秒生成 10 个哈希值的速度，算完一切的 10 位大小写字母和数字组成的弱明码大略须要 P(62,10)/(3600×24×365x10)=1,237,204,169 年期间。

三、一次性用户注册

了解了慢哈希之后，咱们来看一次性完整的用户注册应该是什么样子的。

首先，用户在客户端输入明文明码 123。

接上去，客户端对明码启动加密，可以经常使用 SHA256 散列函数，假构想要审慎一些，也可以经常使用用户名等信息作为盐，以防止彩虹表的攻打。

如今就可以由客户端发送明码到服务端了。

服务端收到客户端发来的信息之后，在服务端眼里可以将客户端发来的明码就当成明文，依照明文的处置流程启动加密并存储，这块松哥在 Spring Security 中和大家讲过屡次了，不赘述。

这就是用户注册的流程。

未来用户登录其实也是一样的。

用户在客户端输入明码之后，如今客户端启动加密，而后再上行到服务端，服务端再依照咱们在 Spring Security 中讲的形式启动处置就可以了。