token 真的安全吗？

[luosuosile]

比如 s 端送出一个 token。 b 端的报文被拦截了，那么不就被拿到了 token 了吗。那攻击者不就能使用这个 token 了吗。 b 端的加密不是没有什么意义吗，因为都能看到。不对称加密我忘光了，在看一次。 都能拦截的话 jwt 和 session 不是一样不安全吗。 那么，拦截报文的难度大吗？ 希望有人给我解释一下，谢谢各位

[luosuosile]

比如我取得 token 不久能进用户主页看各种信息了吗。

[chenset]

所以 https 加密 + B 端不要忽略 ca 验证就可以了.

[chenset]

用于 https 防报文拦截, 证书验证防中间人攻击

[passerbytiny]

首先，怕拦截，就上 https
其次，token 至少能够绑定申请者的的 IP 地址，要求再高的话，操作系统环境、硬件环境都可以要求申请者提供。

[passerbytiny]

再说一句，token 是对称加密，但是加密密钥只在服务器端，只能拦截了模仿，不能伪造。

[luosuosile]

好，来问了就是好。看到文章都说的一知半界。现在又有关键词可以学习了，https，ca 验证。
ip 地址我倒是有考虑过。

[luosuosile]

@passerbytiny 实际上密匙只有服务端知道，所以连对称都好像称不上，但是 b 端又无需解密，加密是为了保护 token 里的用户信息吧？

[luosuosile]

@chenset 好谢谢，我再研究一下

[liuyanjun0826]

在理想情况下楼主说的是对的，但是现实情况下，比如说你拦截我的信息，我肯定会发觉，因为总有第三者存在，除非去掉线下验证

[KyleTung]

token 不是用来做用户信息加密的，而是和 session 一样用来做身份鉴别的，至于安全性还是需要用 https 保证

[opengps]

token 也不安全啊（ https 能做到网络传输半路上不丢），仅仅是个会话标识而已
如果你电脑上或者服务器上，中了某些病毒抓包，那么可以拿 token 来代替你做很多事，这时候 https 帮不了你

[wly19960911]

@luosuosile #7 传统的密码验证就是对称加密，非对称加密是需要两个密钥去分别加密 解密，证书作为公开密钥加密，私钥作为解密密钥，保证除了服务器端没有人可以解密。

这个时候假如你需要进行调试获取 http 明文，就需要网络抓包工具安装一个证书并且劫持所有网站证书替换成抓包工具的，这样抓包工具就可以解密 https。

[watzds]

后端签名鉴权，token 是后端给的啊

[luosuosile]

@liuyanjun0826 那么有什么可以拦截别人报文的方法可以说下吗，我只会 wireshark，findle 这些拦截自己的。

[luosuosile]

@KyleTung 好，看来现在不上 https 都不行了

[luosuosile]

@wly19960911 谢谢，我需要再理解下

[whypool]

https 也能用代理证书抓包

[rogwan]

拦截 token 和获取 token 分开讲，https 拦截 token 是不容易的，否则整个 ssl 加密都失去意义了。获取 token 的方式就比较容易，客户端失控模拟真实访问 s 端很难察觉，为了安全可以配合 ip、csrf 这些一起验证，大厂的风控综合计算的参数就更多了，超过风险阙值就会让用户短信验证，或者客户端扫码登录。

[liuyanjun0826]

@luosuosile 参考 https://github.com/spacecowboy/Feeder https://github.com/DIYgod/RSSHub 即使用代理证书

[luosuosile]

@liuyanjun0826 谢谢

[passerbytiny]

@luosuosile #7 明文得到密文，密文得到明文，两个方向都满足是对称加密，只能满足一个方向就是非对称加密。token 是对称加密。

token 你可以类比身份证，加密（制造身份证）、解密和验证（身份证识别和验伪）都是认证方（身份证管理部门）做的，被认证方（人）只能申请和被认证。

token 的安全性，也可以类比身份证，并没有定论，：一代证只是个有防伪特征的卡片，靠人眼认证，很容易弄个假证；二代是芯片，刷卡认证，不能伪造，但被人捡了就能冒名使用；现在算是 2.5 代，芯片+照片，刷卡+面部识别认证，捡了别人的身份证还要整容才能冒名使用。

[locoz]

上了 https+ssl pinning 之后其实就很难被拦截了，毕竟就算是用户自己想要抓这个包都挺麻烦的，又是装证书又是强制解除 ssl pinning，第三者在没有办法控制用户手机的情况下很难做到这些操作

[tt67wq]

防拦截和防伪造不是一个概念

[liuxey]

HTTPS TOKEN IP UA 这些放在一起，安全级别基本可以应付常见场景

不过我觉得最大的隐患反而在操作系统、浏览器和插件这些端，中间攻击没那么容易。

[dacapoday]

加密 签名 编码 分不清

[mmdsun]

@chenset 有些抓包软件 https 还是可以抓到。这是为什么呢？

[chenset]

@mmdsun 类似 Fiddler 是通过加入自己的根证书到 pc 中实现的, 类似中间人的行为. 实际请求已经被拦截了转发过了, 你可以通过浏览器查看网站的证书 会发现是 fiddler 自己颁发的. 其他的软件无非也是类似方式无他

[chenset]

@mmdsun chrome 下 抓 https 包时你可以通过 F12=>Security=>View certificate 查看证书信息, 发现时被替换了.

[feverzsj]

安全的前提是启用 tls，之后你用什么 token 都无关紧要

[imn1]

token 本身不是用来做保密和安全的，先要明白这点

[terrywater]

token 不要放到 url 里面的参数，放到 request header 里面，这样 https 可以加密

[looseChen]

mark

[chenset]

https 层的东西都已经加密了的, 只有 tcp 层的 src ip & dst ip 没有加密. 所以 url 也是加密的

[Shook]

我的理解是，客户端只是保存 token 作为登陆凭证，服务端收到请求的时候，还是需要进一步解密验证，比如验证 IP 之类的。

[GeruzoniAnsasu]

token 的作用是一次性凭证

假设一次会话是 S1 -> B -> S2
S1 跟 S2 商定好 token，那么 S2 如果能接到 S1 的 token，证明此会话必有 S1 参与，不是 B 凭空造的，它防止的是 B -> S2 的流程未经 S1 授权，（或者说防止没请求过 S1 的什么 C -> S2 ）（ CSRF token ）

假设一次会话是 B -> S1 -> S2
这时候 S1 向 S2 出示 token，作用是防止 B 绕过 S1 的代理直接请求 S2 得到结果，此时 token 保证 S2 收到的请求一定是 S1 发起的而不是其它的什么服务器或浏览器本身 （ SSRF token ）

这些都是在不考虑信道，只考虑逻辑情况下的额外安全措施，首先信道不安全的话 token 可被窃取盗用那安全性是白搭，但就算信道安全，恶意代码也可能通过各种方式混入到请求中，比如存在 UGC 内容里，或者 XSS 从接受输入的地方混入了代码，token 主要防的是混入的第三方恶意请求

[akira]

安全都是相对的啊， 时效性 token 比 账号密码安全