故事卡-短信登录

故事卡-短信登陆：

作为用户，我可以通过手机号和短信验证码登录，以便于我更方便的登录。安全验收标准：

    短信验证码有效期2分钟。
    验证码为6位纯数字。
    每个手机号60秒内只能发送一次短信验证码，且这一规则的校验必须在服务器端执行。
    同一个手机号在同一时间内可以有2个有效的短信验证码。
    保存于服务器端的验证码，至多可被使用3次(无论和请求中的验证码是否匹配)，随后立即作废，以防止暴力攻击。
    短信验证码不可直接记录到日志文件。
    发送短信验证码之前，先验证图形验证码是否正确(可选)。
    集成第三方API做登录保护(可选)。

安全场景1-暴力破解

初始要求:
4位纯数字验证码，有效期5分钟。

存在问题:
非法用户可能在验证码有效期内进行暴力破解找到正确的验证码。

防护策略：
验证码比对即失效删除(无论和请求中的验证码是否匹配)，再次匹配会因找不到对应验证码二失败。

优化防护:
1.6位纯数字验证码，同时缩短验证码有效期2分钟，验证码最多可被使用比对3次(无论和请求中的验证码是否匹配)，正常用户如果不小心输入错误，
仍然可以重新输入，不用再次等待重发验证码，同时可以最大限度防止暴力攻击。
2.增加图形验证码。

安全场景2-资源消耗

初始要求:
不限制短信验证码发送频次

存在问题:
非法用户可能无限制的请求接口发送，可能导致资源耗尽

防护策略：
1.后端检查发送间隔，如每60秒一个手机只能发送一次短信。
2.后端检查单个手机号单位时间发送上限，如每3分钟单个手机号最多只能发送5条短信。
3.后端检查单个IP单位时间发送上限，如每3分钟一个IP最多只能发送5条短信。
4.增加图形验证码。

安全场景3-访问权限

接口必须在经过授权情况下访问，防止公共访问

安全场景4-跨号绑定

用来进行号码绑定的手机号码不是先前发送验证码使用的手机号码

问题:
没有对验证码进行手机号关联匹配

防护:
必须将手机号与验证码进行关联匹配，不可只比对验证码

安全场景5-无效验证

1.客户端提供了验证码输入，但是后端没有任何验证即通过

防护:
必须进行验证码匹配验证

2.业务步骤分离，前一步提供了短信验证码验证，后一步就直接未验证即可提交更改

存在问题:
抓包篡改手机号，可导致提交的手机号不是发送验证码使用的手机号

防护:
需要保证手机号不可从前端提交更改

安全场景6-客户端验证绕过

仅客户端进行验证，服务端不验证

防护:
必须在服务端进行验证码验证

体验场景1-短信验证码到达延时

初始要求:
用户请求发送短信验证码，验证码有效期5分钟，马上收到信息，并输入验证码

存在问题:
用户可能存在网络信号问题，导致60秒后仍未收到验证码，用户再次请求发送验证码，上次的验证码并未过期，这时服务端该怎样处理?

思考策略:
1.存在有效的验证码记录，再重复发送一次(最多重复三次)，用户可能会收到多次相同验证码，但是查看到任意一条短信后输入验证码都正确
2.重新发送验证码，并覆盖删除以前的验证码，至始至终只存在一个有效验证码，但是当前一个短信验证码收到了，用户输入后却会验证失败，因为老验证码已被覆盖删除
3.重新发送验证码，但是追加存储，极端情况会存储5个有效验证码增加暴力破解几率。不过限制了验证码匹配次数3，暴力破解仍有较大难度。

最终策略:
重新发送验证码并追加存储，验证码有效期2分钟，验证码最多匹配3次。

体验场景2-图形验证码

每次都要图形验证码输入，操作多了输入，简单了易被机器识别，复杂了用户失败率高

优化:
可以动态区分一下是否要输入图形验证码，就是识别是否是正常用户及非法用户，可选择集成第三方API做登录保护，后端根据分析结果决定是否要求填写图形验证码