欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

哈希加密的正确姿势——如何科学加盐

程序员文章站 2022-05-12 22:17:07
...
本文地址:https://blog.csdn.net/m0_37595562/article/details/80645984

大家都知道,不管什么系统,只要有用户登录模块的,必然在系统数据库中会存有用户的用户名和密码。用户名明文存储完全没有问题,这里我们就谈谈如何正确地来存储用户的密码。

有些小伙伴可能就说管他怎么存储呢,直接明文存储也没关系。可是这事关我们的信息安全哦!试想一下,如果我们的QQ账号密码都是明文存储在数据库的,那么如果一旦QQ的数据库信息泄漏了。我们的账号和密码信息是不是也泄漏了。那么获得这些信息的人就随意登录我们的QQ号的,这该是一件多么可怕的事情。有童鞋又会说,腾讯的技术那么厉害,怎么可能出现数据库泄漏呢?好,那么我们就不说数据库泄漏,就来说说每个数据库都需要有一些管理维护人员,也就是我们经常听到的DBA。他们的工作也就给了他们权限可以查看一些数据信息,那么大家的QQ用户名和密码就会暴露给他们。不管怎么样,心里至少是有些担心的吧。
当然事实上,也是有公司用的明文存储的密码。时间相对比较早了,在零几年还是10年左右,两家相对还算大型的博客和论坛的数据库信息泄漏了——在这里就不点名了,让人大跌眼镜的是,用户密码竟然都是明文存储。
所以,说了这么多,正确的存储密码的姿势是什么呢?这在Sunny当年开始学后端编程的时候,老师强调过的,密码一定要经过哈希不可逆加密后存入数据库!也就是

密码在磁盘上必须是以加密后的形式存在

而随着经历过的项目越来越多,接触到的密码存储做法也比较多。有直接一个md5函数就放进数据库的,也有做一些特殊处理的,比如加盐。
这边我们还是以md5为例子,给大家展示一下。这里可以给大家推荐一个比较好用的在线md5加密的工具:站长工具。我们先生成一个sunny的md5结果看看,这里选择生成32位大写字母作为结果:
哈希加密的正确姿势——如何科学加盐
生成的密文是:

533C5BA8368075DB8F6EF201546BD71A

然后,我们生成Sunny的密文:
哈希加密的正确姿势——如何科学加盐
生成的密文是:

FFC76083445E28A7E4B314A07A8C3B6A

不了解哈希加密的童鞋从这次示例就能知道了,哈希加密的话,真的是“失之毫厘,差之千里”。这也是它的一个“魅力”所在吧。


另外说一点题外话,其实也不算是题外话,和哈希加密还是息息相关的。早在04年的时候,王小云教授就在一次密码学国际会议上提出了一种可以攻破md5的算法,当然**的思路主要还是在于碰撞。碰撞简单解释一下,就是两个完全明文得出了相同的哈希值。为什么会出现这种情况呢?拿我们刚才生成密文的情况作为例子,如果是32位的密文,那么密文的组合总数只有(26+10)^32这么多,但是如果明文的长度要大于32位或者明文的长度为32位但是包含大小写字母和特殊字符,这样明文的组合数就要大于密文的组合数量,所以必然存在多个明文映射到一个密文的情况。
为什么说这个是题外话呢?这样一来,md5不是已经不安全了吗?我们这里为什么还说md5。事实上,碰撞主要基于明文有较长的长度,至少要比密文要长,通常对文件进行哈希的时候(生成数字签名),需要考虑碰撞的问题,而用户密码通常长度较小,所以相对来说碰撞法较难**。
ps 其实Sunny和王小云教授也算是校友。好了,啥也不说了,默默搬砖去咯。


言归正传,我们来说说如何加盐。

什么是盐

有些童鞋可能对这个名词还有些陌生,这个盐当然不是我们平时吃的盐,也不是化学中的盐,而是一段字符串,用于和明文串接在一起然后哈希得到密文。比如我的密码是sunny (这当然不是真的密码…),然后我的盐为abc,那么拼接在一起就可以是sunnyabc,然后以此哈希后存入数据库。当我再次登录的时候,再将我的密码加盐后哈希与数据库存储的密码比对。

为什么要加盐

我们从暴力**说起,面对一个md5加密的密文,你会考虑这么**。可以跑密码字典,也可以用查表法,包括反向查表,彩虹表之类的。其实本质都是暴力**,只不过现场跑密码字典很慢,而用查表的话,特别是表的数据已经累计到一定程度之后,很可能一查一个准,就有点类似我们的缓存。所以我们需要加盐,即使通过一定的手段得到了明文,在不知道盐的情况下,也会增加一定的**负担。

如何加盐

如何加盐其实主要指的是如何选择盐,通常盐的长度需要较长,短盐的效果可能不是那么好。其实通常各种资料里会建议用一个随机生成的盐。这样能确保每个密文的盐尽量不同,增加**难度。
但是Sunny思考了一下,使用随机生成的盐也是有一定的弊端,较大的弊端就是,这个盐也必须存储,所以也是有机会获取的。所以,我在这里就提出一种思路,至于好不好大家可以讨论一下。
首先,考虑生成的盐是每个用户有所区别的。这一点很重要,作用类似于随机生成的盐。
然后,考虑这个盐不能进行存储,而是可以用现有的用户信息进行生成。这样其实已经很明显了,可以用某种算法利用当前用户的信息(必须是固定不会修改的信息),比如用户id、用户注册时间等。这个算法也可以是哈希加密算法,比如将用户的几个信息进行一定的排序处理之后利用哈希生成盐。


至此,本篇文章到此结束,喜欢的童鞋可以点个赞。
欢迎转载,转载时请注明原文地址:https://blog.csdn.net/m0_37595562/article/details/80645984
童鞋们如果有疑问或者想和我交流的话有两种方式:

第一种

评论留言

第二种

邮箱联系:aaa@qq.com