目前是做了双 token ,但是无法做到跨浏览器复制 token,每次请求附带指纹又太明显,有什么好的安全方案可以尽量控制 复制 token 使用或者 认证安全措施
目前是做了双 token ,但是无法做到跨浏览器复制 token,每次请求附带指纹又太明显,有什么好的安全方案可以尽量控制 复制 token 使用或者 认证安全措施
1
lel020 Jul 29
|
3
blackPanda Jul 29
nginx 客户端认证,但让客户端安装证书挺麻烦
|
4
hxy100 Jul 30
怎么地,楼主你上来问问题的还看不起 DeepSeek 了,真有那么装吗?
|
6
sujin190 Jul 30
不让复制 token 应该属于风控系统,完整的挺复杂的了,但一般情况下用户主动合法复制不用管吧,做请求资源合理性校验就行了,说起来风控系统还挺复杂的,指纹计算啥的其实也只是风控的一部分,但靠这个也对限制效果有限吧
|
7
ShineyWang Jul 30 登录 Session 开始往“绑定设备”发展
Chrome 145 在 Windows 推出了 Device Bound Session Credentials(DBSC)。 假如没有老客户可以试试这个 |
12
skallz Jul 30
很简单,核心诉求是 token 不能被其他设备使用,那对于浏览器来说,能够标识身份的就是 ip 和 ua 了,只要在 token 携带的信息中,加入当时生成 token 时的请求 ip 和 ua ,鉴权时进行验证即可
|
14
aw2350 OP @lel020 我不是看不起 ai ,只是看不起你这种 ,连问题没分析好具体问题在哪,就在大言不惭的说“,你问的还不清不楚,而且连 AI 都没问过,更没人搭理了”。我自己有 gpt plus ,我还不知道去问大模型?
|
16
aw2350 OP @ShineyWang 这个暂时还不是 标准吧?多浏览器、版本兼容起来比较麻烦,已经放弃了
|
17
skallz Jul 30
@aw2350 ip 变更后重新签发 token 就行,不过具体看业务需求是否要这么高规格的风控策略。另外所有数据都是可以伪造的,我们能做的只是提高攻击成本,一般来说只要你不暴露很明显的鉴权所需数据,攻击者是很难从众多数据中找到所需数据,而且还需要比较漫长的分析过程,已经可以拦住绝大部分攻击了,这就足够了
|