V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
kisshere
V2EX  ›  程序员

js 加密, PHP 解密,有没有最好的方法?

  •  
  •   kisshere · 162 天前 · 3327 次点击
    这是一个创建于 162 天前的主题,其中的信息可能已经有所发展或是发生改变。
    基本可以实现前端加密和后端解密,并且较难被破解的方法?
    第 1 条附言  ·  162 天前
    场景为 ajax 发送一个加密的字符串,给后端解密。该字符串的实际内容不想被用户抓包察觉
    47 条回复    2022-03-11 21:21:43 +08:00
    leeyuzhe
        1
    leeyuzhe  
       162 天前
    rsa 不就行了,跟语言没关系啊
    cmdOptionKana
        2
    cmdOptionKana  
       162 天前
    后端向前端发一个公钥,前端用公钥加密,密文传给后端,后端用私钥解密。
    ch2
        3
    ch2  
       162 天前
    ->并且较难被破解的方法?
    js 用 wasm 加密可以增大破解难度,但是本质上只要利益够大迟早会被破解
    watcher
        4
    watcher  
       162 天前
    用 wasm 加个壳吧
    LeeReamond
        5
    LeeReamond  
       162 天前
    没方法,js 加密本身就很迷惑,加密算法无法保密->wasm 虽说可以编译,但解起来也就那回事,数据源也是暴露前端的无法加密,所以加密给谁看呢
    kisshere
        6
    kisshere  
    OP
       162 天前
    @leeyuzhe 这个公钥一抓包不就被破解了
    tagtag
        7
    tagtag  
       162 天前   ❤️ 1
    建议描述一下你的需求,首先前端和后端的通信加密只要有 https 就可以了,除非是你前端产生的内容不想让用户看到所以加密传回后端,但是本质这个需求单纯通过 JavaScript 是不可能的,前端代码对于浏览器本身就是全透明的,你怎么产生的怎么加密的都没什么意义,顶多混淆了代码,看起来费点力气而已,wasm 楼上也说了,存在反编译问题,也只是增加了难度,所以问题应该出在需求上。
    cpstar
        8
    cpstar  
       162 天前
    有个问题,公私钥是不是只针对非对称加密,LZ 需要的是不是一个对称加密,以及密钥分发方案。
    streamrx
        9
    streamrx  
       162 天前 via iPhone
    怎么弄都会被破解, 只要利益超过破解付出的成本
    dzdh
        10
    dzdh  
       162 天前
    场景呢?没场景?

    登录密码加密吗?上 https 足够了,针对这个场景任何前端加密都是脱裤子放屁。

    显示隐私内容?前端输入密码才能看?那应该是后端发来密文吧。
    maichael
        11
    maichael  
       162 天前
    前端加密是个永恒的话题,只能防懒鬼不能防有心人。

    不过有时候还是要看你的需求,毕竟不同的加密需求有不同的解决办法。
    zhanggg
        12
    zhanggg  
       162 天前
    非对称随便弄一个就好了啊,私钥存服务器,公钥发给前端
    公钥加密的内容即使被抓包也解不了啊,又没有私钥

    场景交代的太模糊了,直接建议双向 https 吧,以保证双向信任和内容加密
    就是每次打开你前端界面要贴证书才能访问
    xiangyuecn
        13
    xiangyuecn  
       162 天前
    重要原则:只要代码写的足够复杂,别人就会懒得看🐶,从而增加了破解难度😂。随便搞个位移,base64 过一下 就能糊弄住很大一部分人了
    ch2
        14
    ch2  
       162 天前
    ->该字符串的实际内容不想被用户抓包察觉
    rsa 加密一下就行了,只有有私钥的才能解密
    同一个字符串公钥加密之后每次密文都不一样,谁也不知道内容是什么
    500
        15
    500  
       162 天前
    这是个伪需求
    tagtag
        16
    tagtag  
       162 天前
    简单点就是把加密过程的代码进行大量的混淆操作,增加了读代码难度,复杂点就是把加密工程用 wasm 封起来,毕竟反编译的门槛一下子就上去了。
    sanggao
        17
    sanggao  
       162 天前
    这样加密的意义何在?
    3dwelcome
        18
    3dwelcome  
       162 天前   ❤️ 3
    前端想加密数据有几种方法。

    第一个学 chrome 的 CDP ,给每一个 JSON 传输数据包,都弄一个服务器来维护的自增长 ID 。也就是每个请求就算被黑客抓取到也没关系,服务器的验证 ID 随时在变化,没办法重放。

    第二个学 HTTP2.0 的二进制协议,用 gRPC 来封装 json 数据,对于二进制加密。前端最大的弱点,在于数据都是明文,黑客看一眼就懂。如果是私有二进制协议,他还要花时间分析,还未必能分析出来正确结果。

    第三是学 websocket 的 zlib 扩展压缩,就是客户端和服务器各维护一个动态变化的压缩字典,这样黑客获取获取中间一段数据也没用,他没有对应的字典能正确解压,也是百搭。
    dongtingyue
        19
    dongtingyue  
       162 天前
    @kisshere rsa 公钥只是加密。。。解密是私钥。
    cmdOptionKana
        20
    cmdOptionKana  
       162 天前
    @kisshere 用公钥加密的东西,用户没有私钥,如何破解?
    henyi2211
        21
    henyi2211  
       162 天前
    @cmdOptionKana 公钥加密,私钥解;私钥加密,公钥解
    cmdOptionKana
        22
    cmdOptionKana  
       162 天前
    @henyi2211 楼主说想在客户端加密,在后端解密;同时楼主又担心客户端用公钥加密的东西会被用户破解。我问,用户没有私钥如何破解。
    leeyuzhe
        23
    leeyuzhe  
       161 天前
    @kisshere 公钥随便抓包啊,私钥在服务端,没有私钥拿到公钥也解不出来什么呀
    oldmanong
        24
    oldmanong  
       161 天前 via iPhone
    又遇到了用 12 位密码保护 2 位数余额的场景了😂
    wangritian
        25
    wangritian  
       161 天前
    防中间人,https 足矣;防用户,尤其还是 web ,做不到
    LeeReamond
        26
    LeeReamond  
       161 天前 via Android
    @3dwelcome 对第一种情况,无论如何用户需要正常获取数据,黑客模拟此过程不是同样可以获取数据?

    对于第三种情况,感觉与第一种相同,效果本质上是通过混淆前端逻辑增加查看源数据的成本。但似乎在调试工具下都无太大意义
    LeeReamond
        27
    LeeReamond  
       161 天前 via Android
    另外关于 Lz 的贴条需求,局限在 js 范围内个人感觉无法实现。前端破解有很多专业户,单纯加密逻辑即使搞得很复杂,专业人员理顺可能甚至不需要很长时间
    3dwelcome
        28
    3dwelcome  
       161 天前   ❤️ 2
    @LeeReamond 这问题在 V2 也讨论了很多次了。

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

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

    现在网络安全要求很高,前端加密和后端数据库加密一样,也许很多人眼里看起来用处不大,但不能没有。安全就是一点一滴累加起来的。
    tagtag
        29
    tagtag  
       161 天前
    @3dwelcome 根据题主的描述场景就是有一个字符串是前端生成的要传回后端,不让用户在 DevTools->Network 中看到原始内容,所以就是要把这个内容的 generator 加密或者说隐藏的深一点,感觉您说的都是防中间人的,或者说是防止爬接口的。
    LeeReamond
        30
    LeeReamond  
       161 天前 via Android
    @3dwelcome 最近看到一些动态 js 的说法,很多前端加密公司都提到过,我没见过类似项目所以无法理解是怎样一种加密。一般来说,js 脚本核心数据交互功能还是向服务器请求或发送一段数据,而具体请求或发送的实现可以经过混淆让人无法理解传输的具体内容。不过按照你所说的话,黑客只需要保存某一时刻的所有传输信息,应该就可以解密当时刻下的代码具体行为,之后只需要在浏览器里对目标数据预先劫持就可以永远立于不败之地了,关于你说的让黑客没办法保存 js 我不是很理解
    3dwelcome
        31
    3dwelcome  
       161 天前
    @LeeReamond 动态 JS 可以在原来浏览器 JS 的基础上,再运行另外一套 QuickJS 虚拟机,加密解密就是运行在虚拟机里进行,算法可以在服务器实时生成。

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

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

    以前网上银行都要装一个浏览器插件,只靠原始 JS 绕不过去。
    orangie
        34
    orangie  
       161 天前
    如果目标用户具备网络抓包的能力,那么从用户的技能水平上说,可以说,前端的加密手段应该都对用户无效。
    sampeng
        35
    sampeng  
       161 天前
    很早很早很早微博是不带 https 的。所以他的登陆就是 js 加密。然后我就研究了 1-2 天,大概搞明白了什么个玩法。细节不好说,原理上就是制造一堆参数,用一定算法随机选择。然后,RSA 加密不是要公钥么?任何公钥可以用私钥生成。只是需要一些算法参数。这个就是服务端加密了吐回来的。然后再加密秘文。。我还照着实现了一个

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

    @zyEros

    他有句话说得挺好的

    > 一说到保护安全的问题,大部分人想的是我们要 100%安全
    0o0O0o0O0o
        38
    0o0O0o0O0o  
       161 天前 via iPhone
    @0o0O0o0O0o 我没有用过他的产品,所以不确定强度足够。但我相信只要是设计合理、强度足够的 vmp ,动态的 opcode ,正确的使用方式,破解起来还是没有楼上部分人说得那么轻松的。简单的办法:打开淘宝抓抓包,看看能不能很轻松就把每个加密数据分析出来。
    charlie21
        39
    charlie21  
       161 天前
    这让我想起了 ( csrf 跨站请求伪造,一种网络攻击) csrf 的防御策略之一 csrf token 就是前端给后端发一个数据 后端凭此数据决定是否拒绝访问
    https://tech.meituan.com/2018/10/11/fe-security-csrf.html#前端安全系列(二):如何防止 CSRF 攻击
    就你这个问题而言,具体解决方案 很可能并不在于对明文的加密和解密手段,而在于发送的内容和约定的解密方式。最简单的保密例子是 你可以在发起端发十句谜语,在接收器端决定十句里的第五句谜语是真正起作用的谜语,那么即使在发起端(客户端)抓包拦截到 10 句谜语了 拦截者面对受混淆的信息 并不知道真正起作用的是哪一句,这是服务器端才知道的,那么是不是只要保证解密办法是仅有解密端知道的就可以了呢
    aleen42
        40
    aleen42  
       161 天前 via Android
    lululau
        41
    lululau  
       161 天前 via iPhone
    web 加密难道不是应该用 https 吗。。。
    poplar89
        42
    poplar89  
       161 天前
    好多人在等着 OP 的需求场景,OP 哪里去了 😳
    dany813
        43
    dany813  
       160 天前
    @sampeng 老哥 套娃 牛逼
    sampeng
        44
    sampeng  
       160 天前
    @dany813 只要套的足够多,就没人有闲工夫去一层层剥开
    sampeng
        45
    sampeng  
       160 天前
    其实 99%的需求下,前端加密。
    你以为的:抓包,拿到数据,把 js 代码整理一下稍微阅读,然后看加密逻辑,然后解密。
    实际的:抓包,妈了个蛋,这货居然加密了。。搞不了搞不了。。逃了逃了。。。
    h2ero
        46
    h2ero  
       160 天前
    这种方式没有什么用,只能防下小白用户
    aleen42
        47
    aleen42  
       160 天前 via Android
    如果說需要加密一些敏感數據的傳輸,RSA 是足夠並且在 js 層面是無法破解的。但 RSA 畢竟是非對稱,有其局限性而無法對較大的 request body 進行加密,這時候如果只是考慮對付小白,可考慮 IDEA Cipher 等對稱加密。如果真考慮安全級別,就直接上 SSL 或者通過 worker 做本地端加密吧。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3345 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 41ms · UTC 05:10 · PVG 13:10 · LAX 22:10 · JFK 01:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.