简书 占小狼转载请注明原创出处，谢谢！ 前言 java io操作中通常采用BufferedReader，BufferedInputStream等带缓冲的IO类处理大文件，不过...
发简信
IP属地：浙江
-
深入浅出MappedByteBuffer
-
微信公众号开发与遇坑记
背景 事件起因 某一天运营人员告知产品与技术，微信扫码成功，但是却登录到了另外一个南北相隔的客户账号下面！ 同样是公司下面的微信公众号与其他产品，但是却需要和公司账号关联绑定...
-
-
-
-
-
现在加入java高级架构师：680075317 即可获取Java工程化、高性能及分布式、高性能、高架构。性能调 优、Spring，MyBatis，Netty源码分析和大数据等多个知识点高级进阶干货 的直播免费学习权限及领取相关资料
-
阿sir1990 ·内容没细看，但我对这标题确实无比认同。
jwt最致命的问题，就是将用户标识明文（base64等同明文）的放在客户端，而且单一依赖同一个secret。一旦secret被泄露，那攻击者就可以毫不费力的冒充所有用户。
而不幸的是，secret的保护并不足够：
1. 一般作为配置，总有人容易接触到。（在安全领域，人是最不可靠的）
2. 要更换secret的话，已签发的所有token都将失效（比如知道了secret的人要离职）
3.算法是明文的，所以，攻击者通过暴力破解，有较大可能碰撞出secret，这是因为：
a. 很多人用一些常见或简单的词语作为secret
b. 碰撞时只需要本机运算，不会访问服务器（如果有足够的利益驱动，算力不是问题），也就是说服务端根本不会知道有人得知了secret。
同样，如果有人碰撞出了secret，那他可以任意的构造不同的用户身份而且不会被发觉 -
讲真，别再使用JWT了！摘要： 在Web应用中，使用JWT替代session并不是个好主意 适合JWT的使用场景 抱歉，当了回标题党。我并不否认JWT的价值，只是它经常被误用。 什么是JWT 根据维...
