注意,这个文件必须以UTF-8无BOM格式编码。
一、用户登录模式
密码登录也分为三类: 一类是需要用户输入的文本型密码登录, 一类是手势绘图, 一类就是生物密码。
指纹也算是生物识别的,人脸中只是生物的一种,语音也算生物识别
先说密码登录,密码登录过程中的密码非常关键,这个是识别用户的前提,也就是说,只有密码通过验证了,系统才会认为,系统的当前使用者,才是系统中指定的模型记录,我们知道,系统最大的风险其实就是身份冒用,而这个登录,就是身份认证的第一道关。
前面我们说了几种登录认证方式,从安全角度上来说,安全性肯定不是一个级别的,比如生物识别的安全性肯定要高于其它方式的,所以,在登录场景下,系统往往需要提供一些风控变量,如IP,手机标识等,同时系统中会登记着用户的常用IP,常用终端等,这些环境变量都是系统后台处理的,用户基本上不会有感知的。不同的登录方式,需要搭配不同的风控因子。
二、主流程
我们先说一下主控流程,核心系统收到登录鉴权请求后,是怎么处理的。
- 肯定先要检查登录标识即账号,如手机号存不存在,如果不存在,需要返回异常码给业务系统。
- 如果账号存在,则进入验密阶段,如果验证成功,则找到此用户的系统模型,即用户ID, (USER_ID)。
- 作为核心系统,不只是说密码对了就行了,还要看这个用户本身是不是具有风险,要检查用户的各种状态,还有用户标签,比如用户状态是正常的还是冻结的?用的安全等级是多少?用户是不是被列入黑名单?用户身上被打了哪些标签。
问个问题,如果此时用户被冻结了,对于用户登录这个接口,核心系统应该返回成功还是异常? 应该返回成功,并给出冻结标记,用户登录成功后,不论用户是什么状态,都要将用户基本信息、用户状态、用户标签等统一返回业务系统。这个用户状态的冻结,意味着用户接下任何业务都会受限。比如司法冻结。所以,这个接口要返回成功,及用户基本信息还有其它的信息。
这里有个规定,业务系统收到返回值, 要坚决执行字段语义,比如,业务系统收到 用户密码需要强制修改的语义,业务系统就应该引导用户去修改密码界面。还有,如果用户被冻结,系统也要根据业务规则给用户提示拒绝用户使用系统,特别是用户标签,语义特别多,业务系统根据不同语义做不同的逻辑处理。虽然核心系统不参与业务,不干预业务,但却维护着最基本的业务底线,这是所有业务系统达成的契约,都要共同遵守的。比如,用户已经被冻结,即使业务系统让用户使用系统,但是当用户进行支付的时候,要进行支付密码的签权,此时的支付密码鉴权就会直接抛出异常,而不管用户的支付密码是否正确,系统在返回结果的同时(不论成功还是失败),都要异步的去登记日志,并将事件记入关键事件表。
三、防止暴力破解
检查密码失败次数,原理上是的,核心系统只允许用户在规定的时间内进行一定的次数,如果超过这个限制,就会将密码保护起来,在保护期内,不论用户上送什么密码,直接拒绝处理。所以,在验密的时候,有个错误次数检查和密码是否处于保护状态的一个逻辑处理。由于这种保护只是临时性的,有时限的,所以,过期后要系统自动去保护。 对于登录密码撞库这块,由于是后台处理,我们在支付密码的时候,再讨论
四、其他
大家先消化消化,业务系统这块我没讲,比如用户在登录的时候,业务系统要请求风控系统,对用户当前所处的环境进行一个风险评级,再根据不同的风险评级要求用户上送不同的条件,如是否要外加手机验证码,是否要求用户输入图形码等。这块不属于核心系统的。 登录其实算是最简单的功能了,但是里面还有不少细节需要考虑,大家可以多发挥发挥,我只是抛块砖出来,大家其实也看出来了,每个业务里面都有风控的处理环节。
五、问题
Q1:我插一句 不管何种登录方式登录来源(密码/微信手势手机生物指纹等等) 最终要对应到我们系统的用户 然后生成session 然后分发session 然后完成。业务系统如何获得当前用户的信息 只能通过session反查吧 session可以多级别(可以依赖产生吧)
A1:对于我们的核心系统来说,不关心session,会话由业务系统去保证,因为核心系统是无状态的。刚才说的登录原理是对的,不论哪种登录方式,都是为了验证用户身份,同时找到该用户。 A12:回到你刚才那个问题,用户登录成功后,核心系统会直接把用户信息返回给业务系统,比如用户ID,你说的session是业务系统处理的范畴了,核心系统并不关心。业务系统一般会采用分布式缓存或共享Session的方式,将用户信息进行缓存起来
Q2:我建议在每个业务里面保留风控的钩子,然后做统一的风控模块来接入。风控独立出来整体设计,可能会清晰点。 A2:在设计文档的时候,可以体现出来
六、短信下发
短信下发,是指业务系统的短信下发,可以调用基础设施短信网关,短信网关可以做一些通道备份等。
在短信下发接口里,有着两层业务:
- 短信模版
一般下发短信,都是通过短信模版来实现,不同的业务调用不同编号的短信模版来下发短信。 系统里都会维护一系列的短信模版,并通过占位符约定一些变量,如${RDM}表示随机码,${PRE_MSG}表示在模版前面附加一段文字等
- 验证码的生成
业务系统验证码验证的时候,必须上送调用下发短信时返回的token。如果不用token,系统只能识别到最后一次短信下发的验证码,而且区分不了业务场景。假设在支付场景需要短信验证码,黑客可以欺骗用户在其它环节获取到验证码,从而实现资金盗窃。
除此之外,由于短信下发是需要收费的,所以都会有流量保护:业务系统会有图形验证码来确认是人工操作,同时,核心系统也应该要有发送频率、发送总量的风险控制。
一般情况下,企业都会先建一个基础的短信调用平台,提供基础的调用能力,核心系统通过基础平台实现短信功能
有两个问题大家思考一下,看怎么处理:
Q1. 短信重发,并且需要与上次的验证码内容一致,该如何处理?
A1:短信重发是核心系统的一个接口,短信重发接口需要传递 token,接口业务发现该token存在有效期内的验证短信,就不重新生成,直接重发验证短信。 A12:验证码在有效期内是可以再次重发的,重发后,有效期自动延长,但重发次数不能超过三次。
Q2. 如何避免验证码的多次验证?
A2:验证码前期存在库里就可以了,验证码一般验证完成后,要标注此条失效,验证完的失效,超时的也失效。失效验证码记录,可以移到历史表中。
Q3. 这个时间是验证码的有效时间,验证码的有效时间一般设置多久?
A3. 一般不会超过5分钟。当然,也可以在短信模版中设定好, 做成可配的。
另外,这里容易犯一个错误:将业务系统当成工具系统,因为客户系统具有短信验证码下发功能,很多业务系统都会没有原则的调用此接口,不管这个业务和客户业务有没有关系。为了解决这个问题,客户系统不对外提供短信验证码验证功能,所有验证都和具体业务绑定在一起。