柳晋阳 合格的后端开发者和运维人员需要考虑每个接口的安全性、每个可被公网访问到的服务器的安全性，不要犯错。但是我们还需要考虑，如何在已经犯错的情况下把损失降低到最小。在做数据的存储方案时，我们需要假设储存的数据已经被泄露出去了，如用户密码这种隐私数据的存储就是一个重点。 由于前提1(大家总是到处使用一样的密码)，所以密码泄露之后，再使用撞库，还能得到其他网站的用户密码，对用户造成更严重的危害。比如2014年的12306密码泄露事件里，12306并没有犯错，只是黑客收集了很多其他网站的账号密码，再去12306批量尝试登陆，就可以得到大量用户的12306信息。 所以，后端不应该以任何或可以转换回(如可逆的加密)的形式储存密码。由于储存的信息并不是，所以大多数网站的「找回密码」功能并不能真的告诉你密码，只能让你重新设置一次。如果你发现一个网站的「找回密码」功能真的找回了你的密码，那就要当心你密码的安全性了。 十年前，大多数网站保存的都是经过一次MD5哈希的密码。哈希保存的思很简单:用户注册时，把他的密码做一次MD5运算储存起来;用户登录时，把他输入的密码做一次MD5运算，再验证是否和数据库里储存的一致。 彩虹表就是把简单的数字密码组合(和各种常见密码)的哈希先尽可能的计算出来，这些和哈希结果的对应关系就是一张彩虹表。由于前提2(大家喜欢使用简单好记的密码)，所以试着计算出一个常用范围内的所有字母组合的哈希的彩虹表，可以破解绝大多数人的密码。当彩虹表足够大时，这种存储方式实际上与无异。 在这种储存方式下，一次运算出的彩虹表可以被使用无数次，均摊到每个网站的每个用户的成本是极低的，所以至今仍然有很多服务器在孜孜不倦地运算着md5哈希的彩虹表。这张彩虹表也在大家的努力下变得越来越大。 进行哈希运算。而每个用户的盐值都不相同，之前彩虹表的「一次运算无数次使用」变成了「一次运算一次使用」。这样的成本是难以接受的，由于前提3(成本远高于收益，系统达到相对安全)，所以这是一个比较安全的做法。 这时密钥不应该被保存在数据库里。如果数据库被拖库，那么些数据的安全性与无异。通常会将密钥以变量的形式放在服务器上。这时除非网站在被拖库的情况下同时被拿到服务器权限，否则手机号的就不会被泄露出去。 在后端项目生产里，总是会打印并收集各种各样的日志。日志可以方便统计数据、在出错的时候回溯、调试bug。但是我们不应该总是打印和收集全部请求的正文内容，因为请求里可能包含密码等信息。当日志被泄露时，用户数据同样会以形式直接泄露出去。返回，查看更多
|