这是一个创建于 1958 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情的起因： 之前一直跟安卓和 ios 做 api，使用 jwt 的形式进行交互。
今天突发奇想，如何保证 token 的安全性那。假如我拿到 token 就可以调用服务器端的任何接口。这是多么的可怕。
目前为上线的项目都是 https。
求解？？？
 |
1
oott123 2019-08-22 16:30:55 +08:00  17
假如我拿到你的帐号密码，我可以登录你的帐号，这是多么的可怕。
|
 |
2
miaomiao0323 2019-08-22 16:34:16 +08:00
token 不要放在 get 的参数里，容易通过 referer 泄漏。
|
 |
3
XRR 2019-08-22 16:34:20 +08:00
token 劫持，可以校验登陆的 ip 和调用接口时的 ip,如果有不同就要求用户重新登陆
|
 |
4
diferent 2019-08-22 16:42:47 +08:00 1
@XRR 移动端怎么办. 高铁,开发换基站. 家里移动网络和 WIFI 互换. 互联网场景没有哪家会这么严格的. 除非是银行金融 APP
|
 |
5
baiyi 2019-08-22 16:47:27 +08:00 1
@XRR #3 这样用户体验太差了，不建议这么做
有 https 防中间人就够了，你没有办法保证用户不会丢失 token，就像你没有办法保证用户不会将密码告诉别人一样 不过可以做一些措施保证用户丢失 token 后，你能尽量减少损失，或者通知用户。比如说刷新 token，判断常用 ip 等方法 |
 |
7
jorneyr 2019-08-22 16:48:59 +08:00 1
你拿到 cookie 一样可以调用服务器端的任何接口，所以 token 和 cookie 没有本质区别。
|
 |
8
codeyuyu 2019-08-22 17:00:32 +08:00
所以 安全性强的不会用 jwt，因为无状态和吊销无法两全
|
 |
9
AreYou0k 2019-08-22 17:02:10 +08:00 1
建议用脑电波登录
|
 |
10
arrow8899 2019-08-22 17:12:44 +08:00
汗。。。只要你用了 HTTPS，双向证书校验，数据库密码加密 + hash，日志脱敏，那么别人基本不可能获取到用户的 token，除非用户主动把密码告诉别人，这种你可以参考支付宝的风控技术。
|
 |
11
maichael 2019-08-22 17:18:50 +08:00
你不防中间人，你用啥鉴权都有这问题呀。
|
 |
12
chinvo 2019-08-22 17:19:12 +08:00 via iPhone
如果你认为你担心的问题 https 不能解决，那么你所担心的就是反机器人问题
|
 |
13
guokeke 2019-08-22 17:36:31 +08:00
登录的时候手机二次验证 :>
|
 |
14
flyingghost 2019-08-22 17:50:03 +08:00
假如我拿到你的手机，我可以查看修改你的所有数据，这是多么的可怕！
所以说我们应该抛弃手机吗？ 既然很难有什么技术是“绝对安全”的，我们就需要唾弃所有那些有漏洞的技术方案吗？ 安全从来都是有限制有范围的相对安全。请在明确定义安全防护能力的前提下选择技术方案。 如果你需要考虑 token 失密问题，那就给方案打补丁（比如缩短 token 有效期）或者换方案（比如双端证书）。 如果你需要考虑密码失密问题，那就上指纹上虹膜。 如果你需要考虑手机丢失问题。。。 如果你需要考虑用户已叛国成为间谍问题。。。 你可以无限制的加高安全壁垒，相应的你需要付出相应的成本。 |
 |
15
lurenw 2019-08-22 17:56:14 +08:00
token 不保证安全, 保证安全的是 HTTPS
|
 |
16
tachikomachann 2019-08-22 17:58:38 +08:00 via Android
jwt 有别于其他方式的安全问题在于，不依赖服务端保存 token 的话，无法实现某个 jwt 主动失效（非过期失效）。
所以要么缩短每个 jwt 的有效期，要么还是要服务端再存一份。 |
 |
17
Mutoo 2019-08-22 19:50:35 +08:00
1) Rule-Based Access Control: 将接口权限分散，各 token 执有的权限不尽相同，切不可一个 token 拥有所有权限。
2) 对不同的权限设置合理的过期时间。 3) 传输 token 时使用 https 并把 token 放在 request header 的 auth 字段。保证 token 不被中间人获取，不进入日志系统。 |
 |
18
areless 2019-08-22 20:51:18 +08:00 via Android
jwt 有鬼 ip 客户端特征，就用字符串混淆了一下便是现代 api 的通用方案了（笑）。公网只能判断客户端特征。内网绑定 mac 固化 arp，靠网络技术而非编程技巧了
|
 |
19
Varobjs 2019-08-22 22:19:54 +08:00 via Android
@arrow8899 请教一下，日志脱敏很有必要吗？日志不是给开发调试看的吗，难道不是越详细越好？举个例子，数据库连接失败，密码都错配置了，如果脱敏那就看不到有效信息了
|
 |
20
1762628386 2019-08-22 22:21:45 +08:00
别把 token 当会话使用，一个功能一个 token
|
 |
21
iyaozhen 2019-08-23 00:12:48 +08:00
|
 |
22
xiadong1994 2019-08-23 02:25:33 +08:00
@tachikomachann jwt 有 exp 的 claim 啊
|
 |
23
skiy 2019-08-23 07:22:06 +08:00 via Android
jwt 就没啥安全性可言。之前了解过。还不如直接用 token
|
 |
24
fengpan567 2019-08-23 08:25:43 +08:00
为什么要保证？都拿到了你的 token 或者 cookie 了，说明安全问题已经出现了
|
 |
25
Perolong 2019-08-23 08:33:53 +08:00 via Android
因为一般一个 token 只是能拿到当前用户的权限，并不是 admin 级别的啊，你自己的 token 是删不了其他用户的东西的，如果可以，说明后台偷懒了
|
 |
26
HarryQu 2019-08-23 08:47:38 +08:00 via Android 1
设备生产一个 唯一的 device id， 登录的时候 存储 device id。
同时验证 token 和 deviceid。 |
 |
27
Leigg 2019-08-23 09:23:04 +08:00 via Android
尝试过 jwt，认为不是一个适用于登录登出场景的方案，用户修改密码，注销登陆都不好解决，或者说都需要数据库来辅助实现，倒不如直接使用 token。有 redis 的辅助，可以很方便实现在线用户数统计，用户实际在线时长统计。所以啊，jwt 还是更适用于一次性的数据传输。
|
 |
28
iamdj 2019-08-23 09:34:33 +08:00 via Android
额 按道理说调用后台的话 先解析 token 获取比如说用户名 然后根据用户名再查这个用户有没有权限类似的 怎么就会调用所有接口呢。
|
 |
29
print1024 2019-08-23 10:21:24 +08:00
jwt 只是为了方便系统间交互，并不安全，想安全那就要在网络传输方面下功夫
|
 |
30
dosmlp 2019-08-23 10:32:47 +08:00
用 https 防劫持，至于端的安全你是无能为力的
|
 |
31
Vegetable 2019-08-23 10:34:42 +08:00
你凭什么能拿到别人的 token?
|
 |
32
nikandaoleshenme 2019-08-23 10:42:02 +08:00
1 楼回答已经结贴了，sf 发的帖，又跑这来了
|
 |
33
unco020511 2019-08-23 11:01:05 +08:00
别人拿到你的 token 也没用,你接口如果有签名校验,怎么攻击你,参考支付宝和微信的接口
|
|
34
tachikomachann 2019-08-23 11:09:57 +08:00
@xiadong1994 #22 jwt 的 exp 没法实现服务端主动失效吧？比如用户登出后注销所有会话，用户改密码了，用户被禁用了。
|
 |
35
yule111222 2019-08-23 11:11:56 +08:00
后端也不是有一个 token 就能访问所有服务的呀。。。没有权限控制？
|
 |
36
luozic 2019-08-23 15:53:30 +08:00
token 有啥？没有 RABC 的锅找 token 背？
|
Select Language