这是一个创建于 181 天前的主题，其中的信息可能已经有所发展或是发生改变。
程序是通过解析 jwt 中的用户 userId ， 进行查询的
select * from orders where ownerid = #userId
但是看网上说 不建议将敏感信息 放入 jwt 中， 现在我有点迷惑 这个 userId 到底算不算敏感信息？
说敏感吧，毕竟有 sha256+secret key 加密。 说不敏感吧，如果换成别的 userId ，就可以查询其他用户的信息。
 |
1
leonme 181 天前 via iPhone
userId 很多网站直接露出，你说算敏感信息吗？
|
 |
2
geelaw 181 天前 via iPhone  9
> 说敏感吧，毕竟有 sha256+secret key 加密。 说不敏感吧，如果换成别的 userId ，就可以查询其他用户的信息。
我不知道从何吐槽起了。 |
 |
3
dddd1919 181 天前
如果 id 作为数据表主键或功能外键之类的内部功能字段，建议不要放入 jwt ，除非信息需要展示给用户，否则完全没必要放入
|
 |
4
gbw1992 181 天前
一般情况下都这么干
我个人觉得 userid 也是拿用户名和和密码换的，不是用户信息不算是敏感。 |
 |
5
orangie 181 天前 2
如果不放心，专门设计一个 jwtId ，也做成全局唯一，限制其用途只用来通过 JWT 查找真正的 userId?
|
 |
6
sheeta 181 天前
如#5 所说，redis 映射一个 jwtId => userId 的关系
|
 |
7
tool2d 181 天前
肯定不能用 userId 啊，你看看大厂的用户 oauth API ，全部都是转换成 access token 令牌访问的。
|
 |
8
swulling 181 天前 via iPhone 4
userid 不敏感，但是你们有接口可以允许通过 userid 查询其他人的信息，这个是错误的。没权限控制么？
|
 |
9
hoopan 181 天前
不是敏感，userid 没啥特殊含义
|
 |
10
Jooooooooo 181 天前
"如果换成别的 userId ，就可以查询其他用户的信息"
这是典型的越权. 你再多搜搜 |
 |
11
vopin 181 天前
> 如果换成别的 userId ，就可以查询其他用户的信息
不是有签名吗？内容更换了校验是不成功的呀。 |
 |
12
mayday526 181 天前
@Jooooooooo 越什么权，用户手动修改 jwt 中的 userid ，这个 jwt 就不会认证通过，除非用户知道该系统 jwt 的加密方式
|
 |
13
radiocontroller 181 天前
如果换成别的 userId ，就可以查询其他用户的信息。
前提是加密加签要正确，才能生成正确的 jwt token ，那谁又能拿到你的私钥去做这个事呢 |
 |
14
fuchish112 181 天前
看业务咯，大多数业务是不敏感的
|
|
15
mayday526 181 天前
userid 都要隐藏起来？那你们还要用 jwt 干嘛，为什么不用普通的 redis+自定义 token 的方式，jwt 用来认证一堆鬼问题：自动续期 jwt 如何解决，强制剔除或者使某个 jwt 失效又该如何解决
|
|
16
Jooooooooo 181 天前
|
 |
18
aitaii 181 天前
jwt 不加密的？
|
 |
19
momocraft 181 天前
JWE
|
|
21
tool2d 181 天前
|
 |
24
zjp 181 天前 via Android
补充下#3 的吐槽
如果是根据 userld 就可以查到敏感数据，这是个横向越权的问题 |
 |
25
wheeler 181 天前 via iPhone
> 如果换成别的 userId ，就可以查询其他用户的信息。
那就是敏感。 |
 |
27
vagusss 181 天前 via iPhone
“如果换成别的 userId ，就可以查询其他用户的信息。”
除非能拿到密钥，不然怎么换？ |
|
29
tool2d 181 天前
我再多啰嗦几句，
正常来说 JWT 有两种使用情况，第一种就是替代以前的 cookie user session, 后端加密后端解密，这样对于前端就是透明的存在，的确无法修改其保存内容。 另一种情况，是用于匿名身份验证，比如最近很流行的 Apple Passkeys ，就是用公钥来验证用户 ID 。 换成 JWT 流程也是一样。 第一步在前端 /客户端生成公钥和密钥。 第二步把附带公钥的 JWT 发给服务器，服务器就能自动认证用户的 ID ，因为基本上用户本地生成的公钥，是不太可能有重复的。但是因为私钥留在客户端，还是有一定被篡改的风险。 |
|
30
tool2d 181 天前
@mayday526 去了解一下 acme 的 jwt 使用场景，就是典型的前端加密，后端解密。JWT 是一个完整规范，有多个使用场景，并不仅仅是 session 的替代品。
|
|
32
tool2d 181 天前
@okakuyang 我就觉得既然用了 JWT ，就应该用起来他的身份认证的功能，不要仅仅当黑盒字符串。
否则后端发点别的什么不好，干嘛非要给前端塞一长串的 JSON 保存起来。还不如换成 access token 用户认证，还能附带权限控制。 |
 |
33
oott123 181 天前
jwt 标准中没有加密，只有编码+签名，这意味着：
1. 任何人都能获知 jwt 内编码的信息 2. 除非有 secret 或者 private key ，否则没有人能轻易修改其中编码的信息，这保证了消息的完整性 |
 |
34
coolzjy 181 天前
简单来说，你可以把任何当前用户有访问权限的数据塞到 jwt 中，jwt 能够保证这些数据不被篡改。
|
|
35
mayday526 181 天前
@tool2d 使用场景都不一样，还在东扯西扯。op 的 userid 哪里来的，数据库生成的，后端特意返回个 userid 给前端自己生成 jwt ？
你说的 jwt 黑盒字符串？黑盒？ jwt 不是透明的吗？ 你说换成 token 就附带权限控制？认证和授权是两个步骤，jwt 和 token 第一步都是用来认证的，你非要携带权限控制信息，jwt 就不能携带吗？ 前端生成 jwt 跟裸奔有什么区别？你公司敢这么用吗？请把你公司使用这种方式的网站地址发出来 |
 |
37
dqzcwxb 181 天前
"如果不放心，专门设计一个 jwtId ，也做成全局唯一，限制其用途只用来通过 JWT 查找真正的 userId?"
"如#5 所说，redis 映射一个 jwtId => userId 的关系" 恭喜你,又重新回到了 token 体系的怀抱 |
 |
38
wangxiaoaer 181 天前
1 UserId 算不算敏感要看 id 的生成方式，假如你直接用身份证，那就敏感，如果是 uuid 就不敏感。
2 用户直接更换 jwt 的 userid ，请告诉我用户咋不知道私钥的情况下如何替换？难道后端不做 jwt 校验的吗？ 关于楼上有提到越权的，严格讲这个不算越权，因为 jwt 就代表当前用户身份，就好比有人拦截 cookie 或者碰撞，就可以模拟别人身份操作，这个不属于越权。只不过 cookie 一般人不好拦截或碰撞，而 jwt 是公开的，假如你私钥比较简单，是会被滥用。 |
|
39
wangxiaoaer 181 天前
@tool2d #29
1 JWT 有很多场景，但题主这种很显然就是用来替代身份认证的。 2 Apple Passkeys 我了解不多，但凭常识猜测这个是用在 iPhone 、Mac 等客户端上的吧，这种所谓的客户端是有硬件用来存放私钥等信息的，跟题目这种浏览器客户端压根是两个概念。 |
 |
40
dzdh 181 天前
|
 |
41
watzds 181 天前
你是不懂 jwt 的，也不懂加密和认证
|
 |
42
lanlanye 181 天前
不得不翻出我好多年前读的文章了 [你会做 WEB 上的用户登录功能吗？]( https://coolshell.cn/articles/5353.html)
|
|
43
lanlanye 181 天前
@lanlanye
发完意识到这篇文章没提 JWT ,补充一下： 1. JWT 的意义是保证数据完整性，只能存放公开的信息，user_id 这种东西看场景，大部分时候应该是可以公开的 2. JWT 是无状态的，需要设置较短的有效期，签发后无法在有效期内收回 3. 尽量不要通过在服务端保存签出的 JWT 这种方式来控制其有效性，因为这会使 JWT 失去它无状态的特点，不如直接用回 cookie-session 那一套 |
|
44
tool2d 181 天前
@mayday526 你既然说了使用场景不一样，说明还是能看懂我说的。
https://en.wikipedia.org/wiki/JSON_Web_Token ，里面有一段 use 案例描述，写了有传统后端验证外，还有客户端直接发起 JWT 身份验证两种方式。 作为后者，很适合匿名账户纯客户端直接认证。私钥又不需要在网络传输，只有用户自己能看见，本机不泄漏，就很安全。 |
 |
45
superliy 181 天前
sha256+secret key 这里加密 不是因为敏感而是用于数据校验，不被串改。。你理解方向歪了。。。
|
 |
46
JamChiu 181 天前
jwt 存放的内容本来就敏感，但是加密了，你解密不了也没用，所以有需要就放，没需要就不放~
|
 |
47
leonshaw 181 天前
敏感不敏感是保密性，能不能篡改是完整性，注意区分。
通常所说的 JWT 只保证完整性，关于加密了解下 JWE. |
 |
48
JasperYanky 181 天前
说个不太显眼的用途，如果 userid 是显性连续的，投资机构会用这个估算产品真实的用户规模
|
 |
49
gzf6 181 天前 via Android
后端用唯一用户名查询 ID?
|
 |
50
GeruzoniAnsasu 181 天前
看了这么多楼回复我感觉我也不知道怎么吐槽了
- jwt 本身就是鉴权的令牌，换句话说它本身就是用来防止「知道 userID 查到别的用户信息」的关键设施 - jwt 的关键信息是已登录用户的签名，签名是不可伪造的。至于怎么个不可伪造以及签名如何使用，你们所说的「具体场景有不同用法」，但根本逻辑不会变：通过不可伪造的唯一签名来标识当前请求者是谁 - jwt 不防 csrf 我觉得抓住这三点就够了 |
 |
51
rekulas 181 天前
jwt 的存在不就是为了让分布式节点脱离数据库也能认证么(安全传递令牌或身份验证信息)，当然可以存放私有信息比如 uid （除非你有特殊要求比如普通节点禁止获取用户信息，不在此话题讨论内），如果啥用户信息都不想存放而是放一个映射 id 那用 jwt 的意义是什么，不如直接 token 一把梭
|
 |
53
zhaogaz 181 天前
。。。楼主说的 jwt 内容有事实性错误。。。，建议在学习一下，有标准 rfc 的。。。
如果你想把 user ID 藏起来可以用 JWE id 这种一般算是一般信息，不算敏感，也没必要加密。如果 id 是身份证号那种，那是有必要加密的，让然用它做 id 也不太对。 如果你随便换个 id 能查到其他人信息，这个问题是权限问题。。。 这几句话问题太多了。 |
 |
54
eason1874 181 天前
1 、用户 ID 不算隐私信息，前提是用户 ID 是系统自动生成的，而非邮箱、手机号、身份证号这些用户隐私信息
2 、“换成别的 userId 就可以查询其他用户的信息” 要是这样，就说明你们的 jwt 鉴权逻辑有问题，正常的 jwt 换了一个字节都会导致签名不一样，从而无法通过鉴权 |
 |
55
ixixi 181 天前
觉得有点裸露可以把 userId 用 aes 加密一下 用的时候解密 不影响整体
|
 |
56
urnoob 181 天前 via Android
jwt 延生带用户信息的叫 openid ，一般就是 uniqueid 通常是 uuid 或者加上用户的姓名等非敏感信息。这个 openid 的 token 在获取时通常需要用户授权，权限列表中如果包含查询用户信息，那么这个 token 才可以拿来查询更多用户信息入 email 电话等等
|
 |
57
mmdsun 180 天前 1
如果换成别的 userId ，就可以查询其他用户的信息??
难道不做验签吗？纂改了还能通过 jwt 校验？ 还有那些放信息去 redis 的 那为啥不直接用 session 呢。 本来 jwt 就是节约服务期资源的 |
 |
58
1423 180 天前
需要加密的话，稍微想一下，这跟 ss 的协议设计可能有一样的问题
最终解法可能是 AEAD 。 不考虑 jwt 原本的 Signature 。而是将 AEAD 后的结果给到客户端。 |
 |
59
edis0n0 180 天前
@JasperYanky #48 我前两周做的外包就要求 userid 增量每次随机 1~50
|
 |
60
JaguarJack 180 天前 via iPhone
串改也没用啊。jwt 需要校验。token 是通过 userid=1 生成。改了数据，校验就过不去啊
|
 |
61
iseki 180 天前 via Android
不要把 user id 当隐私信息，id 这种东西保不齐什么地方就露出去了，不要依赖它保证安全性
|
Select Language