登录最佳实践是什么?

2021-11-23 17:44:38 +08:00
 7911364440
7707 次点击
所在节点    Java
39 条回复
sujin190
2021-11-24 09:30:24 +08:00
@banlifeather4 #18 你这个并没有解决问题吧,且不说最简单的设备不在线就走不通,毕竟不是大厂设备在线率不能比,再者用户改密码大多可能有异常登录之类的,既然异常登录了,那说不定 WS 就没用了呢,所以你这个方案是无所谓的正常改密码能正常踢下线,必须要改密码的异常情况恰恰可能反而踢不下线了,反着来么
mosakashaka
2021-11-24 09:34:47 +08:00
jwt 踢用户做点改造不就得了,加个自定义属性。
spring security 没明白为什么不用,而要自己造轮子。。
securityCoding
2021-11-24 09:48:44 +08:00
登录态拦截在网关做,业务中从上下文获取属性即可根本不要关注登录态.省时省力省心
timethinker
2021-11-24 10:03:28 +08:00
登录其实就是认证,认证与授权是两个相对独立的过程。

认证解决的问题:你是谁?一般只是简单的通过标识(用户名)和凭证(密码)来确定身份。确定身份以后,认证系统一般会发放一个 Token (令牌)或者直接绑定身份信息并关联当前的 sessionid (会话,通过 cookie 传递)。

授权解决的问题:在已认证的情况下,也就是我知道你是谁的情况下,你能做什么?

关于密码:不要使用明文,后端也不要接收明文(固然有 TLS ),前端可以使用 BCrypt 慢哈希生成密码摘要,不要在后端使用慢哈希。后端生成(注册)/获取(登录)动态盐值,与前端发过来的摘要结合再次哈希一遍得到最终的摘要信息。

关于 JWT:JWT 只是作为令牌的一种承载形式,它不可伪造,不可篡改,表达了签发此令牌的真实意图,但是不要将敏感信息放进去。好处固然有,例如完全可以在不跟签发者通讯的情况下对其进行验证(签名以及有效期),但是涉及到撤销的情况下,就必须记录每一个令牌的状态( jti 是每一个令牌的 ID ),可以建立令牌黑名单机制,虽然丧失了完全的无状态好处,但是验证这个比较轻量级。

我想说的就是可以根据场景结合混合使用不同的技术,关于安全这一块,不要自己去发明东西,大胆的使用经过时间检验的通用方法,具体如何实现只是细节问题(比如框架,亦或是自己手写),但是在流程上,概念上一定要有清晰的认知。
shuimugan
2021-11-24 13:08:00 +08:00
如果项目前后端分离得很彻底,可以把原来存在 cookie 的 session id 丢到 local storage ,请求的时候取出来追加到 header 上,可以从根本上杜绝 csrf 攻击,还能让扫描器或者等保服务提供商的初级安全人员一脸懵逼
Casbin
2021-11-24 13:12:27 +08:00
可以试试 Casdoor: https://v2ex.com/t/803669 ,支持与 Spring-Boot 项目集成: https://github.com/casdoor/casdoor-spring-boot-example
ihwbunny
2021-11-24 13:17:42 +08:00
为啥没人提多设备验证
danieladu
2021-11-24 16:06:09 +08:00
yangzzzzzz
2021-11-24 16:18:05 +08:00
简单点 jwt 单 token ,复杂点双 token 。
MonikaCeng
2021-11-24 17:31:46 +08:00
我之前做短信登录,安全策略是,同 ip 发短信超过 5 条该 ip 需要验证码。当日短信发送总量超过 1000 条,当日所有人需要验证码
getoffworkontime
2021-11-24 19:04:04 +08:00
直接用阿里云的 API 网关
leeg810312
2021-11-24 23:11:45 +08:00
jwt 那么多好处为什么不用? jwt 跨域方便,横向扩展方便,代码什么都不用改,cookie 和 session 可以吗? jwt 没有提供吊销,但也容易补这个特性。生成时缓存一份,校验前去缓存查一下,吊销时把缓存里的删了就好了。jwt 的好处也用了,缺点也弥补了。
joApioVVx4M4X6Rf
2021-11-25 09:49:28 +08:00
@yangzzzzzz 求教双 token 是啥啊?是 access_token 和 refresh_token 吗
ArmstrongLiu
2021-11-25 10:41:27 +08:00
@qwe520liao #24 关于“关于密码” 这块有两个疑问:

1. Bcrypt 哈希算法每次生成的哈希值都是不同的(即使是相同的密码),这样后端是如何校验密码的正确性的呢?

2. 前后端交互时不使用明文的原因是什么?如果出现别人通过抓包或者请求拦截获取到密码或者密码摘要,这二者造成的后果是不是都是一样的?因为不管是用密码或者是密码摘要模拟请求,后端的密码验证都是可以通过的。
timethinker
2021-11-25 13:03:36 +08:00
@ArmstrongLiu
1 、前端 Bcrypt 是可能的,我们需要的就是把“慢”这个过程放到客户端内,代码细节可以看一下我刚创建的这个测试,需要一个固定的盐值: https://jsfiddle.net/4zdw1jab/

2 、不使用明文不仅仅只是说为了传输上的考虑,明文就是“烫手山芋”,只要生成摘要的过程是安全可靠的,其实我们根本就不需要明文。其他的顾虑包括但不限于意外的日志输出或者其他的安全漏洞,所以彻底的做法就是后端根本就不接收明文。当然这一条只是作为一个建议,如果手动模拟注册请求给后端接口发送的就是明文,那么当然也可以模拟登录用之前的明文,关于这种“非法”注册的用户,当然也就排除在正常的产品流程之外了。
ZeroDu
2021-11-25 15:38:09 +08:00
自己写个拦截器 + uuid +redis 无烦恼。
yangzzzzzz
2021-11-25 16:09:18 +08:00
@v2exblog 是的
ArmstrongLiu
2021-11-26 11:05:15 +08:00
@qwe520liao 如果前端使用固定盐值,那应该没有问题。我之前使用 python ( passlib.hash )进行测试时一直没有使用盐值,所以它每次都自动生成 salt ,就导致每次的 hash 值不同。
letitbesqzr
2021-11-29 11:08:19 +08:00
sa-token 好用

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/817469

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX