md5 彩虹表

彩虹表(Rainbow Table)是一种主流的密码破解技术,它事先把所有可能的密码计算出哈希并保存在索引文件中,在需要破解时只需根据哈希对索引文件进行查询即可很快获得明文密码,在避免大量的重复计算的同时,也大大提高了密码的破解速度。



相比暴力破解方式彩虹表的速度更快,而相比字典破解彩虹表的成功率更高,对特定密码空间的彩虹表破解成功率高达99%以上。既然彩虹表破解技术这么高效,那我们使用密码还有什么意义呢?其实不然,彩虹表并不能破解所有密码。



首先,彩虹表只适合对MD5/SHA1/NTLM等不加盐的基础哈希算法,加盐意味着给密码添加了一个随机字符串,这使得对同一个密码进行哈希每次得到的结果都不一样,所以也就无法使用查询预先运算结果的方式来破解。



其次,彩虹表采用以空间换取时间的策略,在提高破解速度的同时,彩虹表的保存需要占用大量的存储空间。比如8位以内的大小写、数字及特殊字符组合密码,其彩虹表体积达到了1T,而且密码每增加一个位,体积就增加几十倍,所以彩虹表适合对长度比较短的密码进行破解

https://baijiahao.baidu.com/s?id=1671536764163474839&wfr=spider&for=pc



给密码加盐



第一阶段
最开始接触web开发时,对于用户表的密码基本是明文保存,如:



username | password
———|———-
zp1996 |123456
zpy |123456789
这种方式可以说很不安全,一旦数据库泄漏,那么所以得用户信息就会被泄漏。之前,国内普遍采用这种方式,造成了很多的事故,如csdn600万用户信息泄漏、12306用户信息泄漏等。



第二阶段
本人大学做过的所有的项目基本采用的都是这种方式来保存用户密码,就是对密码进行md5加密,在php中md5即可,在node中利用crypto模块就好:



const encrypt = (text) => {
return crypto.createHash(“md5”).update(String(text)).digest(“hex”);
};
作为初学者的我,认为这种方式是很安全的,因为md5不可逆(指攻击者不能从哈希值h(x)中逆推出x)而且碰撞几率低(指攻击值不能找到两个值x、x’具有相同的哈希值);然而这种方式也是不安全的,只要枚举出所有的常用密码,做成一个索引表,就可以推出来原始密码,这张索引表也被叫做“彩虹表”(之前csdn600万用户明文密码就是一个很好的素材)。



第三阶段
这种方式是在实习中学习到的,也就是对密码来进行加盐。



什么是加盐?
在密码学中,是指通过在密码任意固定位置插入特定的字符串,让散列后的结果和使用原始密码的散列结果不相符,这种过程称之为“加盐”。



加盐很好理解,就是给原始密码加上特定的字符串,这样给攻击者增加攻击的成本,加盐的关键在于如何选择盐:



固定字符串
采用固定的字符串作为盐,如下面这样:



const encrypt = (text) => {
text = text + ‘zp’;
return crypto.createHash(“md5”).update(text).digest(“hex”);
};
这种加盐方式与多进行几次md5一样的,没有任何意义,攻击者都可以拿到数据库,难道拿不到源代码吗,根据源代码攻击者很轻松的就可以构造新的彩虹表出来逆推密码。



随机字符串
盐一般要求是固定长度的随机字符串,且每个用户的盐不同,比如10位,数据库可以这样存储:



username | password |salt

———|————————————|———-
zp1996 |2636fd8789595482abf3423833901f6e |63UrCwJhTH

zpy |659ec972c3ed72d04fac7a2147b5827b |84GljVnhDT
采用的加密方式为:



md5(md5(password) + salt)



https://www.kancloud.cn/zhangchio/news/642381



为什么md5是不安全的?
,你可以把这个网站理解为一个超级大的彩虹表,你可以反向查找hash对应的明文,当然只能查找到在表里面的数据了。



1.0时期:数据库中明文存储账号和密码
2.0时期:数据库中存放账号和密码的hash值
3.0时期:给你的密码加点盐
4.0时期:多重验证
微信认证,支付宝认证
生物指纹:人脸,指纹
短信验证码等等



https://blog.csdn.net/lineuman/article/details/114893282
https://blog.csdn.net/luyaoda1202/article/details/48930075
https://blog.csdn.net/Saintyyu/article/details/102583941



Category algorithm