这是一个创建于 720 天前的主题，其中的信息可能已经有所发展或是发生改变。
- jwt 的密钥怎么存储，怎么防止内部人员泄露
- 参考 jwt ，自定义算法是否可行，如： token: 时间戳.userid.hashcode[加盐] 其中时间戳和 hashcode 采用 62 进制字符表示。 主要作用是缩短 token 长度。
 |
1
yusheng88 OP hashcode = murmurhash(盐+时间戳+userid)
|
 |
2
LindsayZhou 2022-12-03 12:30:05 +08:00
第二个问题，类似的，我翻过 https://sr.ht/~sircmpwn/sourcehut/ 的代码，他们生成 cookie 和 OAuth2 token 的方法，都是从 go 的结构体生成 BARE Message ( https://baremessages.org/)，然后加个 HMAC 签名 （ https://git.sr.ht/~sircmpwn/core-go/tree/master/item/crypto/crypto.go )。
|
 |
3
dzdh 2022-12-03 12:30:28 +08:00
1. 使用 rsa ，每个 ID 的私钥都不一样。视需要的安全程度比如可以开发一个专门的认证服务私钥在这个服务里面生成、保存。
2. jwt 只是个协议，算法和表述可以自己定义不用过分拘泥于形式。如果用什么三方包那就干掉自己实现一个。也就两个方法事。 |
|
4
dzdh 2022-12-03 12:32:05 +08:00
docker registry 的 jwt 使用是自定义 CA 生成证书，给每个 ID 生成证书，证书内容在 payload 里，认证时使用 ca 公钥验证证书合法性再验证签名。
|
 |
6
iseki 2022-12-03 13:03:50 +08:00 via Android
看一看 Linux 的 keyring 机制？不管是不是 jwt ，凭据存储都是个问题，我看大多都无所谓了，直接往哪一丢谁爱看谁看了…
|
 |
7
momocha 2022-12-03 13:11:53 +08:00 via iPhone
jwt 客户端需要考虑对签名证书链的信任，一般都会内置证书的公钥来认证签名的有效性。
服务器上有私钥当然如果能拿到就没有安全性可言，一般证书管理都会有专门的服务来避免直接接触到私钥。 |
|
9
dzdh 2022-12-03 15:27:01 +08:00
@yusheng88 如果是开发一个认证服务，那么私钥的生成和签名的验证都是在这个服务内部维护的。外部是接触不到的。或者说不想干的开发者是拿不到的。这个服务还是内网访问的，根据 0 信任模型搭建并维护这个服务。
|
 |
10
dorothyREN 2022-12-03 17:12:34 +08:00
jwt 密钥 程序启动随机生成吧，程序重启所有签名失效 我觉得挺好的
|
|
12
yusheng88 OP @dorothyREN 这样确实能解决私钥保存的问题，但感觉也丢失了分布式单点登陆的特色...
|
 |
13
fengpan567 2022-12-03 23:04:19 +08:00
如果怕秘钥泄露可以上 aws 的 kms 服务
|
|
14
dzdh 2022-12-03 23:22:31 +08:00
还有一种是统一信任网关。
所有请求（无论内部还是外部）都经过网关传递流量到后端服务，后端服务只要验证请求来自网关就行了(如客户端证书，客户端是指网关，服务端则是真正的服务)。 |
 |
15
edis0n0 2022-12-03 23:46:53 +08:00
@dorothyREN #10 程序重启所有签名失效 那你们上个新版本所有用户都要重新登录？
|
 |
16
sch1111878 2022-12-04 21:13:59 +08:00
@edis0n0 也不是不行 😂
|
Select Language