js 加密， PHP 解密，有没有最好的方法？

[kisshere]

基本可以实现前端加密和后端解密，并且较难被破解的方法？

[henyi2211]

@cmdOptionKana 公钥加密，私钥解；私钥加密，公钥解

[cmdOptionKana]

@henyi2211 楼主说想在客户端加密，在后端解密；同时楼主又担心客户端用公钥加密的东西会被用户破解。我问，用户没有私钥如何破解。

[leeyuzhe]

@kisshere 公钥随便抓包啊，私钥在服务端，没有私钥拿到公钥也解不出来什么呀

[oldmanong]

又遇到了用 12 位密码保护 2 位数余额的场景了😂

[wangritian]

防中间人，https 足矣；防用户，尤其还是 web ，做不到

[LeeReamond]

@3dwelcome 对第一种情况，无论如何用户需要正常获取数据，黑客模拟此过程不是同样可以获取数据？

对于第三种情况，感觉与第一种相同，效果本质上是通过混淆前端逻辑增加查看源数据的成本。但似乎在调试工具下都无太大意义

[LeeReamond]

另外关于 Lz 的贴条需求，局限在 js 范围内个人感觉无法实现。前端破解有很多专业户，单纯加密逻辑即使搞得很复杂，专业人员理顺可能甚至不需要很长时间

[3dwelcome]

@LeeReamond 这问题在 V2 也讨论了很多次了。

上次讨论的结果是，前端加密一下，总比什么都不管，不加密要好。

也不能用静态密钥，不安全。需要算法来动态生成密钥，算法会频繁更新，让黑客没办法保存 JS ，也没办法反编译。都是服务器实时下发的动态脚本，必须联网才能获取。只要用户一直联网，就能限制访问频率和提高破解门槛。

现在网络安全要求很高，前端加密和后端数据库加密一样，也许很多人眼里看起来用处不大，但不能没有。安全就是一点一滴累加起来的。

[tagtag]

@3dwelcome 根据题主的描述场景就是有一个字符串是前端生成的要传回后端，不让用户在 DevTools->Network 中看到原始内容，所以就是要把这个内容的 generator 加密或者说隐藏的深一点，感觉您说的都是防中间人的，或者说是防止爬接口的。

[LeeReamond]

@3dwelcome 最近看到一些动态 js 的说法，很多前端加密公司都提到过，我没见过类似项目所以无法理解是怎样一种加密。一般来说，js 脚本核心数据交互功能还是向服务器请求或发送一段数据，而具体请求或发送的实现可以经过混淆让人无法理解传输的具体内容。不过按照你所说的话，黑客只需要保存某一时刻的所有传输信息，应该就可以解密当时刻下的代码具体行为，之后只需要在浏览器里对目标数据预先劫持就可以永远立于不败之地了，关于你说的让黑客没办法保存 js 我不是很理解

[3dwelcome]

@LeeReamond 动态 JS 可以在原来浏览器 JS 的基础上，再运行另外一套 QuickJS 虚拟机，加密解密就是运行在虚拟机里进行，算法可以在服务器实时生成。

对黑客来说，虚拟机就是字节码，看不懂。字节码可以埋地雷，必须按照一定的顺序执行，这能一定程度防止恶意修改，提高破解难度。

由于密钥算法是动态的，随时在变。那么下发的虚拟机字节码，也随时在变。保存的 JS 算法会过期，自然也就没有保存 JS 代码的意义了。

[LeeReamond]

@3dwelcome 大概理解了，意思是需要秘钥验证的场景，前端每次加密前都要向后端请求加密代码，而后端每次提供以不同逻辑加密的代码，使黑客即使解出单次请求的逻辑也无法复用。不过感觉上这个适合的应该是前端往后端发送数据的场景，对于接受数据保密的需求则无效。另一个问题在于，发送数据一般都需要通过基础设施获取，但 js 虚拟机我看到的一般是实现 es5 ，也就是说不管是 input 这类用户输入，或者从 navigator 这类基础设施获取数据，本身无法在虚拟机内部执行，如果获取后再输入的话，这个获取过程就很容易被预先劫持

[3dwelcome]

@LeeReamond 是的，劫持确实是一个很大问题。

以前网上银行都要装一个浏览器插件，只靠原始 JS 绕不过去。

[orangie]

如果目标用户具备网络抓包的能力，那么从用户的技能水平上说，可以说，前端的加密手段应该都对用户无效。

[sampeng]

很早很早很早微博是不带 https 的。所以他的登陆就是 js 加密。然后我就研究了 1-2 天，大概搞明白了什么个玩法。细节不好说，原理上就是制造一堆参数，用一定算法随机选择。然后，RSA 加密不是要公钥么？任何公钥可以用私钥生成。只是需要一些算法参数。这个就是服务端加密了吐回来的。然后再加密秘文。。我还照着实现了一个

其实我觉得吧，前端加密都是防君子不防小人，只要你的内容足够他有用大量的时间研究，就没有解不开的，所以前提如果是你的数据重要到绝对都不能让对方知道，你为什么要用 WEB 网页的方式提供内容。参考银行，证券，就是绝对不能随便被抓包拿到数据的。。。又想简单，又想安全。对不住，没有银弹。。如果只是想给破解者增加麻烦，套娃就是了，越复杂越好。。只要解密成本大于你实际数据成本，就没人干这个事。我干过最复杂的事就是，把硬件编号，每一个用一个不同的算法加密，然后最后结果再套 3 层不同 key 的加密。。而且整个东西是二进制文件，内存里本身就是加密的，只有在使用的一瞬间，从十个不同的内存快拿 n 字节的数据拼起来，再解密。。。。谁爱破解谁破解去吧，毁灭吧。。随便

[GitContract]

直接 https 不就完了吗

[0o0O0o0O0o]

我记得本站有个做 js vmp 的，有商业化产品，应该能提高破解难度。

@zyEros

他有句话说得挺好的

> 一说到保护安全的问题，大部分人想的是我们要 100%安全

[0o0O0o0O0o]

@0o0O0o0O0o 我没有用过他的产品，所以不确定强度足够。但我相信只要是设计合理、强度足够的 vmp ，动态的 opcode ，正确的使用方式，破解起来还是没有楼上部分人说得那么轻松的。简单的办法：打开淘宝抓抓包，看看能不能很轻松就把每个加密数据分析出来。

[charlie21]

这让我想起了 （ csrf 跨站请求伪造，一种网络攻击） csrf 的防御策略之一 csrf token 就是前端给后端发一个数据 后端凭此数据决定是否拒绝访问
https://tech.meituan.com/2018/10/11/fe-security-csrf.html#前端安全系列（二）：如何防止 CSRF 攻击
就你这个问题而言，具体解决方案 很可能并不在于对明文的加密和解密手段，而在于发送的内容和约定的解密方式。最简单的保密例子是 你可以在发起端发十句谜语，在接收器端决定十句里的第五句谜语是真正起作用的谜语，那么即使在发起端（客户端）抓包拦截到 10 句谜语了 拦截者面对受混淆的信息 并不知道真正起作用的是哪一句，这是服务器端才知道的，那么是不是只要保证解密办法是仅有解密端知道的就可以了呢

[aleen42]

IDEA Cipher: https://github.com/aleen42/IDEA