安全开发之身份鉴别

很多搞开发的“盆友”可能身处初创民营企业，心里眼里都是赶快实现激动人心的功能。成为下一个jobs。其他的事情都嫌麻烦不去想，或者也没有这个环境和意识去想。

但是，如果幸幸苦苦开发出来的产品（网站）上线后，却遭受了无情的黑客攻击或上级主管部门的安全通报，对这个刚刚种下的“小树苗”的发展也不太好，给我们成为jobs的路上制造了不小的障碍。

所以，我想着是不是能写一个安全开发系列（先想着，看我现在这种搬砖人，哪里需要去哪里搬砖的架势，也只是先想着），让开发的“盆友”和产品经理在设计功能的时候就把一些安全问题规划进去。

今天，先说一下身份鉴别。

我看有的公司门户官网是静态页面，没有用户注册和登录入口。但是呢，一般来说现在的web和APP都是有交互功能的，也就是需要用户登录后进行交互。那么就要求对登录用户进行身份标识和鉴别。

这点很好理解，搞开发的都有这种常识性的概念，要有身份唯一性标识，比如MySQL数据库中为保存用户标识的列设置unique（唯一性约束）。然后用账号+密码来做鉴别。

但是，这里又有一个密码复杂度的问题，也就是说用户注册时设置的初始密码需要是强密码，比如长度大于8位，包含了数字、字符、字母两种以上的组合。还不能是键盘按照顺序敲击得出的密码（如1qaz2wsx这种）。总之一句话，咱就不能让用户密码是个弱密码。

接下来又要站在攻击者的视角看问题，黑客如果使用暴力破解的方式来拿到身份鉴别信息怎么办？所以，我们不能让这种事情发生，我们得做严格一点的登录策略，也就是说要有登录失败处理功能。比如，连续输错密码5次，锁定10分钟。也要有不好被机器识别的图形验证码，滑动拼图这类，来防止黑客用自动化工具进行暴力破解。

光顾安全还不行呢，你要考虑到如果呆呆人忘记了密码，反复尝试多次被锁定又急着用的情况，那么要给这类呆呆人友好的体验，得允许其使用注册时的约定信息进行密码重新设定。

看上去一切都很完美了，开发的盆友也许要说，晓得了晓得了，放我过去吧！我还急着开发呢。

oh，No。我们还要考虑，你把用户的密码是加密还是明文存储在数据库中的？可以用数据库查询语句去看看。

select * from users

如果是明文存储，这下有麻烦了，增加了被攻击的暴露面，特权人员也能看到这些敏感信息。然后黑客万一把数据库攻破了，也拿到了这些敏感信息，可以去撞库（懒得解释了，不清楚这个专业名词的朋友去网上查查），做更大的破坏行为。

已经比较完美了， 如果你把这些都做到，一般针对身份鉴别的合规都能满足要求。不过，还可以加一条，比如，用户做重要的功能操作，比如修改密码，订购退订业务，查看敏感信息，需要再次鉴定用户的身份标识。这是防范越权的。

当然对于比较严格的合规，可能还需要你做多因子身份鉴别，暂且不表，我们先把基础的了解。

总结了一下，有好几条，我列成清单供君参考。

THE END

原文始发于微信公众号（透明魔方）：安全开发之身份鉴别