用户表如何存放用户密码

原创
2018/07/31 00:59
阅读数 159

先上结论:密码安全性从低到高

数据库存密码原文<数据库存密文(成本=彩虹表)<数据库存加固定盐(固定盐甚至不能被称为盐)的密文(成本=计算出盐值+制作彩虹表)<数据库加随机盐的密文(成本=用户数*制作彩虹表)<(随机盐+固定盐+原文)加密(成本=计算固定盐值+用户数*制作彩虹表)

我们都知道,密码存原文,这在现在几乎是不可能的,用户密码一般以密文的形式,存放于表中。如果仅仅是对密码做一层加密,那么当用户表数据泄露时,倘若黑客以彩虹表逆向破解密文,加密的密文实际上破解难度并不大(成本=彩虹表,网上现成的),这是因为一些用户的密码并不复杂。所以我们需要在加密的过程中,加入盐值,将密码原文和盐值一起加密。而盐值如果是固定的值,实际上也等于没加,因为如果密码原文一样,盐值一样,最后产生的密文值仍然是一样的,但是这种加固定盐的方式,可以加大彩虹表破解的难度。因为黑客需要知道盐是什么,才能通过彩虹表破解(成本=计算出盐值+制作彩虹表)。但是我们不能把希望寄托于黑客不知道盐的情况(这样就违背了密码学准则),虽然一般来说,数据库数据被盗取的可能性,大于源码被破解的可能性(当然了库能拖走,源码也能反编译),甚至黑客可以注册一个用户,密码123456,通过看数据库里的密文,反向计算出固定盐值,所以这种方法安全度不高。从密码学的角度来说,我们希望哪怕两个用户的密码原文是一样的,但是数据库里存放的密文是不一样的。这时,有一种常用的办法,就是加随机盐,盐值随机产生,这样就可以保证用户密码原文一致,但密文不一致。那么就出现了一个新的问题,随机盐怎么获取?有人说产生一个随机数,例如用户注册时间,没错,那么我们在判断密码是否正确的时候,需要知道盐值是多少,换句话说,如果我们使用随机盐,我们就需要保存随机盐,那只能保存到数据库中,可是前文已经提到前提:数据库数据泄露的情况下。那么所谓的随机盐,也就是一个笑话了。当然了,随机盐的手段,更能提高黑客破解的难度,哪怕黑客获取了数据,他也需要针对不同的盐,制作不同的彩虹表才能反向破解,这大大提高了黑客的成本(成本=用户数*彩虹表)。还有一种手段,比上述加密更难以破解,就是采取随机盐+固定盐一起,作为盐值,数据库表里以某个字段的值作为随机盐,比如用户注册时间、创建时间、手机号、用户名等等,源码里设置一个固定盐,以此来作为真正的盐加密。甚至可以为了复杂度,截取随机盐的某几位,将固定盐MD5作为盐值等等(成本=计算固定盐值+用户数*彩虹表),其实说实话,计算固定盐值的难度,远远低于用户数*彩虹表的难度,因为一个是沉没成本,一个是边际成本。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部