token 真的安全吗？

[luosuosile]

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

[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 比 账号密码安全