后端 PHP 给浏览器发送一个密钥，怎样才尽可能不被发现？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2571 天前的主题，其中的信息可能已经有所发展或是发生改变。

前端 js 和后端 php 公用一套加密解密系统，公用一个密钥，php 加密的字符串传到前端通过 js 进行解密，现在这个加密和解密函数的密钥想尽可能不被别人发现，该怎样实现？

用 ajax 二次请求密钥，但是 F12 一抓包就暴露了
把密钥写进一个 png 图片（类似二维码）里，通过 js 结合 canvas 来读取，但是 IE 表示无能为力
通过 cookie，input hidden 这些就更暴露了
append 一个 script 标签，通过 jsonp 的形式加载，跟 ajax 一样，一抓包就暴露了
websocket ？因为 IE, 不考虑

求好心 V 友们，有没有好点的办法？

密钥

PHP

解密

加密

47 条回复 • 2017-11-10 20:18:04 +08:00

algery

2017-11-09 11:35:27 +08:00

传到客户端还叫密钥吗

orancho

2017-11-09 11:36:29 +08:00

HTTPS + 非对称加密

dndx

2017-11-09 11:38:21 +08:00

总是有人觉得自己能不用 TLS 达到“安全”。事实证明都是在自欺欺人。

xiaxiaocao

2017-11-09 11:39:10 +08:00

这应该是个伪需求。
先讲讲为什么要加密传给 js 吧

gdtv

2017-11-09 11:39:15 +08:00

HTTPS 就行了啊，或者：请到本公司现场获取密钥字符串

picone

2017-11-09 11:40:53 +08:00

WebSocket 也是明文

可以考虑非对称加密，如 RSA 这些算法，公钥大家都知道，私钥只有你知道，用户端用公钥加密了，只有你服务器端有私钥才能解密。

有一些例子，比如之前分析过百度的登录页面，他们就是用 RSA 加密。公钥，指数放在 js 上面写死了，登录时候密码就加密了。
另外一个是网易云音乐 PC 端的页面，F12 发现他们 POST 的数据是加密的，然后我单步调试了下，他们是生成一个密钥，然后用 RSA 加密，然后拿加密前的密钥用 DES 加密，然后把 DES 加密后的内容和 RSA 加密后的密钥发送到服务器。这样做是因为 RSA 运算量很大（大数运算），POST 的数据量很大（ POST 之前的数据还是 JSON 编码的），如果都用 RSA 的话会很慢。

linxiaoziruo

2017-11-09 11:41:06 +08:00

秘钥的名字取的迷惑一点，让人从字面意思上看不出来这是秘钥。这是没有办法的办法。但是我还是要说，秘钥用这种方式传递，这个思路方向本身就是错的！

fe619742721

2017-11-09 11:41:08 +08:00

前端所有的内容都是暴露的。。解密过程被暴露就会被追踪到密匙啊，怎么隐蔽传输都没有用
除非你用 https 那套逻辑来进行密匙管理，但是太复杂了点

isCyan

2017-11-09 11:42:01 +08:00 via Android

非对称加密，用户生成密钥，把公钥传给服务器，服务器加密后返回，客户端密钥解密。外面再套一层 HTTPS 防止中间人

testcaoy7

2017-11-09 12:53:09 +08:00

SRP 可以，服务器不储存密码，只储存 verifier
客户端有密码，不上传服务器，只用来计算 challenge
challenge 可以通过网络，被抓包也没关系，因为不能反向推算密码

SRP 过程如果通过，服务器和客户端会各自计算出一样的密钥，用于加密通信

testcaoy7

2017-11-09 12:54:54 +08:00

这里有个例子
https://github.com/RuslanZavacky/srp-6a-demo

tabris17

2017-11-09 12:54:55 +08:00

周末去广场裸奔，怎样才尽可能不被人发现？

tabris17

2017-11-09 12:56:16 +08:00

思路就是错的，使用私钥的计算都应该放在服务器上进行

sampeng

2017-11-09 12:57:27 +08:00

如果不上 https 的话，8 楼是正解。
我也分析并且仿造新浪的来过一波。效果不错。但无法处理回放攻击和中间人攻击。。病毒 or 脚本可以很轻松的 get 到 http 请求，然后回放登陆，https 可以避免这种情况

msg7086

2017-11-09 12:57:49 +08:00

@tabris17 黑人，在夜晚，不容易被发现。注意不要睁大眼睛，也不要张嘴。

anuan

2017-11-09 12:59:21 +08:00

希望不被谁发现呢

SummerWQM

2017-11-09 13:39:13 +08:00

很好奇这是一个要实现什么产品的思路

cctv1005s927

2017-11-09 13:52:05 +08:00

这是一个不可能实现的问题，任何在浏览器上的东西都是公开的，你无法加密。

只有在客户端里面的东西才能加密。

我在公司有过这方面的时间，调查了很久，最终放弃了加密的方式

linescape

2017-11-09 14:05:27 +08:00

嗯再造一个依照 https 的轮子然后废弃直接用 https

dangyuluo

2017-11-09 14:09:26 +08:00

记得某事业单位用的一个客户端，验证用户名密码不是在服务器端，而是客户端把用户名发给服务端，服务端返回用户的密码，客户端进行比对。

BOYPT

2017-11-09 14:10:33 +08:00

很简答啊，让用户根据页面提示拨打你的电话，你告诉他密钥让他输入。

findTheWay

2017-11-09 14:18:14 +08:00

js 和 php 共用同一个加密解密方法，js 端的公共方法加一下密，不知道加密后的 js 方法难能不能使用。这只是一个思路

gouchaoer

2017-11-09 14:46:50 +08:00

js 和 php 都用 aes 对称加密密钥 key，这个 key 是 js 生成的
然后这个 key 用 rsa 的公钥加密后传给 php，php 用 rsa 的私钥解得到 key，然后用 key 来解密得到数据

gouchaoer

2017-11-09 14:48:57 +08:00

你都用了 https 了就没必要了，因为浏览器里的东西都能被看光光

Tokin

2017-11-09 15:28:55 +08:00

@dangyuluo 没有 get 到高明之处。。。密码还是在网络中传输了哇？在客户端对比密码的话，不一样有泄露风险么？可能我有点菜。。。

moonsola

2017-11-09 15:42:30 +08:00

@Tokin 网络中传输的肯定不是密码明文，拿到也没用

DOLLOR

2017-11-09 15:52:06 +08:00

先说清楚不被谁发现？
运营商、中间人：HTTPS 足矣，其他都是徒劳。
用户：什么也不做。没有哪个客户会无聊到关心你的代码、密钥，折腾这个只是浪费时间。
其他好事者、F12 玩家：什么也不做。任何东西到了浏览器内部后，一切都暴露出来，你千方百计地隐藏，最多只是提高一点门槛。

Tokin

2017-11-09 16:46:39 +08:00

@moonsola 既然不是明文，那要在客户端解密。。。为啥不在客户端加密上传到服务器呢？虽然我现在都是 https+明文传输。。。

imxieke

2017-11-09 19:24:17 +08:00 via Android

@msg7086 现在广场普遍有路灯 (⁄ ⁄•⁄ω⁄•⁄ ⁄)
可以试试把脸蒙上露个眼

dnartz

2017-11-09 20:19:56 +08:00

迪菲-赫尔曼密钥交换，但是如果没有 HTTPS 证书信任，浏览器还是有可能被中间人劫持。

odoooo

2017-11-09 20:33:48 +08:00

推荐你看看 1Password 的白皮书，TLS 是安全的，如果你对安全等级要求高，不要完全依赖他。

odoooo

2017-11-09 20:35:33 +08:00

https://1password.com/files/1Password%20for%20Teams%20White%20Paper.pdf

odoooo

2017-11-09 20:59:02 +08:00

As discussed in Transport Security
we make use of TLS but do not wish to rely on it.

iVanilla

2017-11-09 22:42:32 +08:00 via Android

两年前我也考虑过，但这是不可能实现的

silencefent

2017-11-09 22:43:45 +08:00 via Android

其他浏览器用 canvas，检测到 ie 直接发明文，我觉得用 ie 的人大多用不到 f12

dangyuluo

2017-11-09 23:20:12 +08:00

@Tokin 在客户端比对这就是问题所在啊。

yingfengi

2017-11-09 23:26:24 +08:00 via Android

@msg7086 这算不算 https

qq292382270

2017-11-09 23:28:39 +08:00

不用纠结这些事.. 不管怎么做都有破解方法的 ..
只有提升破解难度.让破解者觉得得不偿失..才能达到效果..

wtcoder

2017-11-10 01:21:27 +08:00

Flash 不谢~

linescape

2017-11-10 08:47:23 +08:00

@gouchaoer 然而还是防不了中间人

LeeSeoung

2017-11-10 09:16:53 +08:00

楼上所有说的方法都只能防一时。。在会逆向的人眼里都是小菜。。

ck65

2017-11-10 09:35:45 +08:00 via iPhone

求佛。

nilai

2017-11-10 10:06:22 +08:00

不考虑中间人替换流量，只防中间人监听的话，不上 HTTPS，就一招 DH 算法就够了，

catinred

2017-11-10 10:27:08 +08:00

@nilai 前端浏览器的 js 跑 DH 算法的性能估计很低楼主直接上 https 不就完事了吗？

Tompes

2017-11-10 11:36:42 +08:00

后端加解密才是正途，浏览器端都是果体..

killerv

2017-11-10 12:31:39 +08:00

你这思路就是错的，只要发送到浏览器，没有什么是不能看到的。最多进行非对称加密看不到内容是什么意思。不知道为什么这么多人说 https，https 最多就是防止运营商，你能防止用户看到 https 内容？

elevioux

2017-11-10 20:18:04 +08:00

题主加密的目的是什呢？

防止中间人获取信息？那直接上 https 就好啊。

浏览器端的所有信息都是暴露给用户的，再怎么隐藏都是可以通过 js 知道你的密钥放哪里的。