kyuuseiryuu

看了下代码，有点意思。
主要就是浏览器端生成密钥对，拿公钥作为识别移动端和桌面端的 ID 。
公钥通过二维码带到移动端。
移动端将公钥和公钥加密后的密文发送给服务器
服务器通过公钥找到对应的桌面端，将加密文本发送给桌面端有桌面端生成的私钥解密填充。

也许楼主把帖子标题改成《一种跨设备信息加密传输的方案》会更好一点。

针对第二条附言，因为他们增加用户绕过他们的客户端的难度是为了防止自己的业务不被恶意利用，。

二次验证要解决的问题是“确认本人授权”。

如何保证就涉及到两个核心点

1. 动态验证
2. 仅本人可知

仅本人可知这一点需要验证设备仅被本人拥有。

动态验证需要设备产生的验证信息与服务端同步。

OTP 方案就是服务端和客户端使用相同的随机数种子，生成两端同步的验证码。

再就是公私钥对，自己保存私钥，公钥告诉服务端，服务端生成随机数给客户端，客户端加密后服务端用公钥解密。

以此来证明此时登陆的用户是拥有验证设备的“本人”在授权登录。

你都已经假定后端是不安全的了，前端 HTML 不也是做后端的同一个公司的人做的吗，它怎么就更安全了呢？更何况前端代码是任何一个人都能拿到的。

对于社工来说，只要能拿到能登陆的那一串字符串就够了，他根本不在意你那串字符串背后的含义。前端加密唯一的好处就是可以给模拟请求增加难度仅此而已。

明文传输给后端不代表数据库里保存的就是明文呀。

通过配置 salt ，入库的时候混淆哈希完全可以防止被脱裤撞库的。

利用中间件也可以防止敏感信息被记录在日志里，这点就要靠开发者或者公司的规范来保证了。

前端加密方案面对的攻击者是用户本身，他攻击的目标是你网站的业务。

敌人都没有分清楚是谁一顿花里胡哨输出有什么用？

两边内网都整一个装了 tailscale 的旁路由网关呗

啥都要 gas fee ，成本挺高的。做出来了没人玩。

@pyy910716 手机短信发完就删了就好了。要躲的话最传统的方式最好。

双方都有加密的的需求，那为什么要在微信沟通？