- 主题:jwt相比普通token,优势在哪?
拿到 sessionid 发动重放攻击跟 csrf 攻击是两件事。我原本就是分成两段话来讨论的。你为啥非常要混在一起呢?
至于 jwt 能不能做 csrf,要不你来说说后端不搞 session 的方案吧。
【 在 eGust (十年) 的大作中提到: 】
: 我服了,为啥用 jwt 就不能做 csrf 了?
: csrf 防的只是给你嵌一个 get 链接这种弱智攻击,人家说的情景都拿到 session id 了,你一个 csrf 有啥用?
--
修改:hgoldfish FROM 111.142.201.*
FROM 111.142.201.*
旧的 jwt 要不要通过验证?
【 在 eGust (十年) 的大作中提到: 】
: 一样啊,csrf 就是一个 random token 而已,我后端再生成一个 jwt 把 random token 和用于身份验证的 jwt 都签在一起不就完了?
--
FROM 111.142.201.*
讨论一个技术,难道不能跟竞品技术比一下生态圈?session 管理的生态圈显然比 jwt 强大太多。
这也是我为什么在前面说,或许是 android/java 还有 nodejs 程序员的 http 库缺少 session 管理能力,所以比较热衷于这个技术。
【 在 eGust (十年) 的大作中提到: 】
: ……
: 这东西好不好用跟你已有系统或者现有系统用不用有啥关系?
: 你要是开发个百八十人用的东西,或者本来跑得好好的服务,还非得拿掉 session 重新用 jwt 那是自己作。这跟技术本身有啥关系?
: ...................
--
FROM 111.142.201.*
以前也见过有人用 fernet 加密自定义格式的 token.
不知道 fernet 这个对称加密方法还有没有其它的用途。
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 看来与原来的区别主要是标准化,其次是 标准包含了加密和签名。
: 时带来无法及时 invalid 掉特定 token 的问题,所以服务器端 stateful 也很常见。
: 用。
: ...................
--
FROM 111.142.201.*
你这种讨论需求的方法我经常在 apple 版看到。
【 在 eGust (十年) 的大作中提到: 】
: 我发现几乎所有人都被你这个伪问题带沟里去了
: 检测到不正常业务都是直接封权限。挑 session 是什么鬼,难道是天朝人力太便宜了,养了一堆吃饱了没事儿干的运维?公司局域网里电脑中毒了难道不是是拔网线,处理完了再拿回来,而是进安全模式接着凑合用?
: 敏感业务需要输密码确认,如果还不够的话采用多步认证,比如密码器、u 盾之类的。靠运维给用户使用错误擦屁股,真不知道该评价是企业级应用还是开玩笑
: ...................
--
FROM 111.142.201.*
jwt 这种也算新技术啊。。本青多年前就往 response 里面写 json 加密头了。每种技术都有优势和劣势,仔细分析才能应用到开发里面。你不要抓个新玩具都像拿到金羊毛一样高兴好不好。
要不我再放个大招吧。要说句不客气的话,放在整个软件开发领域,某个社区一票层出不穷的东东都不配叫”新技术“。
【 在 eGust (十年) 的大作中提到: 】
: 最后我还想多说一点,跟技术本身无关。如果你带着偏见去看一门技术,就会连 csrf 怎么在 jwt 里面实现这种问题都能问的出来。不是针对某个人,老鱼别想太多。这是一个普遍现象,不光天朝,不光码农,全世界的人都一样。
: 随着年龄的增长,除了注意身体健康以外,我也是时刻提醒不要用抵触的心态去看新东西。这可能跟本科时的教育有关,当时老师的大意是,政客认为正确的东西,都是他大学时代的知识。引申出去,人到了一定年纪就不容易接受新知识了,这跟人们普遍的印象,年纪越大的人越不容
: 前两天看到一个吐槽,我觉得道理是一样的,道格拉斯·亚当斯的科技三定律:
: ...................
--
FROM 111.142.201.*
不是说 session 能避免 csrf,我是说在 sessionid 技术下很容易解决。而在 jwt,还得引入 fallback 方案。额外的开发是小事,但我估计很多程序员估计会直接省掉吧。
要我看,jwt 需要在非常大规模的 web 开发,以至于 session 存储的开销成为重大问题的情况下才能应用。以及应用在非 session 相关时。现在被误用得太厉害了。
session 不要存储在 redis 里面这一条倒是很有意思。可以说说。
【 在 menghan (skybluee) 的大作中提到: 】
: 没有哪种方案是绝对安全的,都需要 trade off
: csrf 只会发生在 web 场景,为什么呢,因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题,不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
: sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道",而在于是否自签名。
: ...................
--
修改:hgoldfish FROM 111.142.201.*
FROM 111.142.201.*
但为什么用 session 就一定会依赖”大规模“分布式存储呢。jwt 不用大规模分布式存储的”优势“依赖于 session 管理必须用”大规模“分布式存储这个劣势。再者,多大算大规模呢?分布式存储可是动不动玩 PB 级别的数据。。TB 级我看是没多大规模。
再来就是大规模分布式存储很麻烦这件事。问题就来了,真的很麻烦吗?又不是 ceph/swift 这种对象存储、块存储。就算是使用分级存储的情况下,我觉得也真心很简单了。
不能用 redis 存储这件事是比较反后端程序员直观的,也刚好跟本线索的”大规模分布式存储“有关。有兴趣可以聊一下。
【 在 menghan (skybluee) 的大作中提到: 】
: 我明白你想知道 jwt 到底比 session(id) 方案好在哪儿,其实我已经说了,可以通过算签名比对的方式不依赖大规模分布式存储。
: 但是你觉得这有什么了不起,对不对,session 的方案已经很全很完善了,依赖一个存储有啥问题,更何况说不定可以使用 redis,redis 又快又方便,为什么要开发另一类东西。
: 我想说,你对大规模,对什么叫分布式存储,一无所知啊
: ...................
--
FROM 111.142.201.*
你还是仔细看一下前面的帖子吧。上面几个人在说 jwt 要做 csrf 得依赖 fallback 方案了。
顺便说一下想拿 jwt 来代替 session 还有一个问题。jwt 如果要主动失效旧的 token,那用户就不得不总得重新登录。这通常是反用户体验的——别跟我说什么不安全,这就是业务需求。而 session 方案,存个天长地久都没问题。
【 在 eGust (十年) 的大作中提到: 】
: 给你找台阶下……都不新鲜了还问 csrf 怎么生成这种不用动脑子的问题
--
FROM 111.142.201.*
其实,可以想出很多优化方案的,这件事情我刚好干过。我甚至用 c++ 写过一个仿 redis (内存+fork bgsave)的分布式存储方案。
【 在 xWvxYWYxvWx (xWvxYWYxvWxxWvxYWYxvWx) 的大作中提到: 】
: 基于 Redis 的“大规模分布式存储”本身就很麻烦。
--
FROM 111.142.201.*