前端把加密算法写进 wasm 内，如何防止别人直接调用 wasm 获取加密结果

没啥好办法吧。

我之前也这么想过

把流程逻辑也写到 wasm 里吧

- 获取加密结果有什么用
- 用公钥加密

敝帚自珍

前端从后端获取临时 token ，传给 wasm ，wasm 里面校验临时 token 是否合法

防止不了。

wasm 应该有跨域保护的吧

没办法防止，退一步来说，即使 wasm 里有校验，我直接度 html 的内容呢，我直接截屏再 ocr 识别呢，我拍照再 ocr 识别呢，归根到底是成本问题，只要获取成本大于获利成本，别人就不会费这功夫了

@passon 获取临时 token 又套另一个加密算法，哈哈哈哈。

前端没有办法。除非有加密芯片。

我能做这种加密，我写的前端加密算法浏览器自己都解不出来

先别管渲染效果怎么样，你就说加密有没有用吧

wasm 也是可以被逆向的

那么折腾，不如直接把加密算法放后端。

从本地的 CSP/P11 读取密钥进行解密

防个啥，又不是 app 还能加固

如果是为了防止反推明文可以用非对称加密

不如先说说你的场景，想访谁

wasm 调用 js 读取加密数据源，而不是暴露加密接口给 js

让操作系统保存密码比较合适，像浏览器保存的密码想看需要输入 windows 账户密码，那样。

和后端一样，上一些手段，做一些请求参数安全认证并混淆提高安全等级，但依然会存在被破解的风险

为啥老有人想着浏览器是绝对安全的？任何场景下就不要相信接入方不就完了。wasm 读去就读去了。。他愿意折腾折腾呗

比如我想研究 aws 的登录。。。好家伙。真的好家伙。10 多个变量和头。再见。。没那本事

非对称加密

用 wasm 已经拦住大部分人了。剩下的在策略上折腾把，前端折腾不出花来，特别还是浏览器。

js 加密太累了，这样吧。
已知存在多个 xorhash1(xorhash2(data))=xorhash3(data)
服务端 xorhash1(encrypteddata),客户端 xorhash2 二次加密后拿去 wasm 验证 xorhash3 。
如果发现被破解，直接同时换 hash1 和 hash2 ，这样客户端被破解的 js 必须替换，否则无法过 hash3 。
好处是 wasm cache 可以不用重新加载。(如果你的加密算法很重很大的话）

不要把有关安全的东西放在前端