第 96 题：介绍下前端加密的常见场景和方法
目前在前端开发中基本都会用到加密，最常见的就是登录密码的加密。接下来会为大家介绍几种加密方法。
1. md5 加密
MD5 加密后的位数有两种：16 位与 32 位。默认使用32位。 （16 位实际上是从 32 位字符串中取中间的第 9 位到第 24 位的部分）为提高安全性。根据业务需求，可以对md5 添加偏移量。如对原有字符拼接指定位数的字符串。
使用方法
npm install --save js-md5
// 然后在页面中 引入
import md5 from 'js-md5';
md5('holle') // bcecb35d0a12baad472fbe0392bcc043扩展 md5 支持算法
md5.hex(''); // d41d8cd98f00b204e9800998ecf8427e
md5.array(''); // [212, 29, 140, 217, 143, 0, 178, 4, 233, 128, 9, 152, 236, 248, 66, 126]
md5.digest(''); // [212, 29, 140, 217, 143, 0, 178, 4, 233, 128, 9, 152, 236, 248, 66, 126]
md5.arrayBuffer(''); // ArrayBuffer
md5.buffer(''); // ArrayBuffer, deprecated, This maybe confuse with Buffer in node.js. Please use arrayBuffer instead.
md5.base64(''); 2. base64 加密
npm install --save js-base64
// 引入
let Base64 = require('js-base64').Base64
// 加密
Base64.encode('测试'); // 5bCP6aO85by+
Base64.encodeURI('测试'); // 5bCP6aO85by-
// 解密
Base64.decode('5bCP6aO85by+'); // 测试
// note .decodeURI() is unnecessary since it accepts both flavors
Base64.decode('5bCP6aO85by-'); // 测试3. res 加密
前端 js 库：jsencrypt.js github 地址: github.com/travist/jse…
背景：前端数据加密传到后台，后台经过解密，进行数据处理。 在项目开发过程中，为了保证数据的安全性，在进行前端后端数据传输的过程中，需要对数据进行加密解密。
现在比较安全且流行的加密方式是非对称加密（RSA）。其加密方式需要两个秘钥：私钥（私有秘钥）和公钥（公开秘钥）。公钥加密，私钥解密。
RSA 加密规则
公钥（publicKey）加密、私钥（privateKey）解密。不能逆向，私钥（privateKey）加密、公钥（publicKey）解密。说白了就是前后端都需要用公钥（publicKey）进行加密，用私钥（privateKey）进行解密。
为啥不可逆呢？前端代码的安全性差，是总所周知的。之所以称为私钥（privateKey），就是因为是私密的，不可公开的，需要确保 key 的安全。若前端私钥（privateKey）加密，就意味着需要将私钥放到前端保存，这是不安全的，也违背了确保数据安全的初衷。
RSA 双向加密解密
在开发过程中遇到这样一个问题：前端不光要加密数据传到后端，也需要将后端的传回来的加密数据解密。所以定义了两个方法，进行数据的加密解密。
引入前端 JS 库：jsencrypt.js
// RSA 解密
static decryptRSA(str: string) {
const encryptor = new JSEncrypt() // 新建JSEncrypt对象
const privateKey = "XXXX" // 私钥串
encryptor.setPrivateKey(privateKey)//设置私钥
const decrytStr = encryptor.decrypt(str)
return decrytStr
}// RSA 加密
static encryptRSA(str: string) {
const encryptor = new JSEncrypt() // 新建JSEncrypt对象
const publicKey = ''; //公钥串
encryptor.setPublicKey(publicKey) // 设置公钥
const rsaPassWord = encryptor.encrypt(str)
return rsaPassWord
}相信大家已经发现问题了，我们将私钥（privateKey）、公钥（publicKey）全部都放到了前端代码中，前端的安全性差，可以很轻松的拿到秘钥对，RSA 加密解密也失去了价值。那该如何解决这个问题？
通过前后端的沟通，我们采用双向加密解密，就是使用两套秘钥来解决这个问题。何为双向加密？
后端定义两对秘钥：秘钥对A、秘钥对B。
秘钥对 公钥 私钥
A publicKeyA privateKeyA B publicKeyB privateKeyB
后端拿着：私钥 A（privateKeyA）、公钥 B（publicKeyB），前端拿着：公钥 A（publicKeyA）、私钥 B（privateKeyB）。
秘钥对A – 前端加密，后端解密
前端使用公钥A（publicA）对数据进行加密，后端通过公钥A（publicKeyA）对应的私钥A（privateKeyA）进行解密。
秘钥对B – 前端解密，后端加密
后端使用公钥B（publicKeyB）进行加密，前端通过公钥B（publicKeyB）对应的私钥A(privateKeyA)进行解密。
这样就能保证，虽然私钥（privateKeyB）和公钥（publicKeyA）都在前端代码中，但是这两个并不是一对，就算是全部拿到，也无法成功解密。也符合公钥（publicKey）加密、私钥（privateKey）解密的规则。完美解决！
注意事项 这个插件对res加密的字符串最长是 117字符，
有时加密时，会遇到加密参数过长而无法加密的现象在源码中加入以下代码，通过调用encryptLong方法，重新定义加密函数即可。
JSEncrypt.prototype.encryptLong = function(string) {
var k = this.getKey();
// var maxLength = (((k.n.bitLength()+7)>>3)-11);
var maxLength = 117;
try {
var lt = "";
var ct = "";
if (string.length > maxLength) {
lt = string.match(/.{1,117}/g);
lt.forEach(function(entry) {
var t1 = k.encrypt(entry);
ct += t1 ;
});
return hex2b64(ct);
}
var t = k.encrypt(string);
var y = hex2b64(t);
return y;
}
catch (ex) {
return false;
}
};
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
前端进行密码传输最好也使用不可逆加密
WebAssembly 防盗链
base64可逆，所以仅从加密这点看和没加密没区别吧？
这里就需要后端进行消息签名和防伪策略了，发现伪造直接丢弃甚至加入黑名单
说到这里发现密码加密还是不安全，还是可以伪装登录，不管怎么前端还是后端加密，比如你一旦捕获到用户登录api请求的账号和密码的时候，通过接口请求获取token等就可以伪装了，是这样么
https://wooyun.js.org/drops/Web%E5%89%8D%E7%AB%AF%E6%85%A2%E5%8A%A0%E5%AF%86.html
有个问题，密码传输这块，使用base64转码再解码，这种模式的应用场景是哪些
首先，加密的目的，简而言之就是将明文转换为密文、甚至转换为其他的东西，用来隐藏明文内容本身，防止其他人直接获取到敏感明文信息、或者提高其他人获取到明文信息的难度。
通常我们提到加密会想到密码加密、HTTPS 等关键词，这里从场景和方法分别提一些我的个人见解。
场景-密码传输
前端密码传输过程中如果不加密，在日志中就可以拿到用户的明文密码，对用户安全不太负责。
这种加密其实相对比较简单，可以使用 PlanA-前端加密、后端解密后计算密码字符串的MD5/MD6存入数据库；也可以 PlanB-直接前端使用一种稳定算法加密成唯一值、后端直接将加密结果进行MD5/MD6，全程密码明文不出现在程序中。
PlanA
使用 Base64 / Unicode+1 等方式加密成非明文，后端解开之后再存它的 MD5/MD6 。
PlanB
直接使用 MD5/MD6 之类的方式取 Hash ，让后端存 Hash 的 Hash 。
场景-数据包加密
应该大家有遇到过：打开一个正经网站，网站底下蹦出个不正经广告——比如X通的流量浮层，X信的插入式广告……（我没有针对谁）
但是这几年，我们会发现这种广告逐渐变少了，其原因就是大家都开始采用 HTTPS 了。
被人插入这种广告的方法其实很好理解：你的网页数据包被抓取->在数据包到达你手机之前被篡改->你得到了带网页广告的数据包->渲染到你手机屏幕。
而 HTTPS 进行了包加密，就解决了这个问题。严格来说我认为从手段上来看，它不算是一种前端加密场景；但是从解决问题的角度来看，这确实是前端需要知道的事情。
Plan
全面采用 HTTPS
场景-展示成果加密
经常有人开发网页爬虫爬取大家辛辛苦苦一点一点发布的数据成果，有些会影响你的竞争力，有些会降低你的知名度，甚至有些出于恶意爬取你的公开数据后进行全量公开……比如有些食谱网站被爬掉所有食谱，站点被克隆；有些求职网站被爬掉所有职位，被拿去卖信息；甚至有些小说漫画网站赖以生存的内容也很容易被爬取。
Plan
将文本内容进行展示层加密，利用字体的引用特点，把拿给爬虫的数据变成“乱码”。
举个栗子：正常来讲，当我们拥有一串数字“12345”并将其放在网站页面上的时候，其实网站页面上显示的并不是简单的数字，而是数字对应的字体的“12345”。这时我们打乱一下字体中图形和字码的对应关系，比如我们搞成这样：
这时，如果你想让用户看到“12345”，你在页面中渲染的数字就应该是“23154”。这种手段也可以算作一种加密。
具体的实现方法可以看一下《Web 端反爬虫技术方案》。
参考
HTTPS 到底加密了什么？
Web 端反爬虫技术方案
可以说的秘密-那些我们该讨论的前端加密方法
前端加密那点事
关于反爬虫，看这一篇就够了