为什么要在MD5加密的密码中加“盐”

原文地址:http://www.xttblog.com/?p=986

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

以上这句话是维基百科上对于 Salt 的定义,但是仅凭这句话还是很难理解什么叫 Salt,以及它究竟起到什么作用。

第一代密码

早期的软件系统或者互联网应用,数据库中设计用户表的时候,大致是这样的结构:

1 2 3 4 5 6 7

mysql> desc User; +----------+--------------+------+-----+---------+-------+ | Field    | Type         | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | UserName | varchar(50)  | NO   |     |         |       | | PassWord | varchar(150) | NO   |     |         |       | +----------+--------------+------+-----+---------+-------+

数据存储形式如下:

1 2 3 4 5 6 7

mysql> select * from User; +----------+----------+ | UserName | PassWord | +----------+----------+ | lichao   | 123      | | akasuna  | 456      | +----------+----------+

主要的关键字段就是这么两个,一个是登陆时的用户名,对应的一个密码,而且那个时候的用户名是明文存储的,如果你登陆时用户名是 123,那么数据库里存的就是 123。这种设计思路非常简单,但是缺陷也非常明显,数据库一旦泄露,那么所有用户名和密码都会泄露,后果非常严重。

第二代密码

为了规避第一代密码设计的缺陷,聪明的人在数据库中不在存储明文密码,转而存储加密后的密码,典型的加密算法是 MD5 和 SHA1,其数据表大致是这样设计的:

1 2 3 4 5 6 7

mysql> desc User; +----------+--------------+------+-----+---------+-------+ | Field    | Type         | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+-------+ | UserName | varchar(50)  | NO   |     |         |       | | PwdHash  | char(32)     | NO   |     |         |       | +----------+--------------+------+-----+---------+-------+

数据存储形式如下:

1 2 3 4 5 6 7

mysql> select * from User; +----------+----------------------------------+ | UserName | PwdHash                          | +----------+----------------------------------+ | lichao   | 202cb962ac59075b964b07152d234b70 | | akasuna  | 250cf8b51c773f3f8dc8b4be867a9a02 | +----------+----------------------------------+

假如你设置的密码是 123,那么数据库中存储的就是 202cb962ac59075b964b07152d234b70 或 40bd001563085fc35165329ea1ff5c5ecbdbbeef。当用户登陆的时候,会把用户输入的密码执行 MD5(或者 SHA1)后再和数据库就行对比,判断用户身份是否合法,这种加密算法称为散列。

严格地说,这种算法不能算是加密,因为理论上来说,它不能被解密。所以即使数据库丢失了,但是由于数据库里的密码都是密文,根本无法判断用户的原始密码,所以后果也不算太严重。

第三代密码

本来第二代密码设计方法已经很不错了,只要你密码设置得稍微复杂一点,就几乎没有被破解的可能性。但是如果你的密码设置得不够复杂,被破解出来的可能性还是比较大的。

好事者收集常用的密码,然后对他们执行 MD5 或者 SHA1,然后做成一个数据量非常庞大的数据字典,然后对泄露的数据库中的密码就行对比,如果你的原始密码很不幸的被包含在这个数据字典中,那么花不了多长时间就能把你的原始密码匹配出来。这个数据字典很容易收集,CSDN 泄露的那 600w 个密码,就是很好的原始素材。

于是,第三代密码设计方法诞生,用户表中多了一个字段:

1 2 3 4 5 6 7 8

mysql> desc User; +----------+-------------+------+-----+---------+-------+ | Field    | Type        | Null | Key | Default | Extra | +----------+-------------+------+-----+---------+-------+ | UserName | varchar(50) | NO   |     |         |       | | Salt     | char(50)    | NO   |     |         |       | | PwdHash  | char(32)    | NO   |     |         |       | +----------+-------------+------+-----+---------+-------+

数据存储形式如下:

1 2 3 4 5 6 7

mysql> select * from User; +----------+----------------------------+----------------------------------+ | UserName | Salt                       | PwdHash                          | +----------+----------------------------+----------------------------------+ | lichao   | 1ck12b13k1jmjxrg1h0129h2lj | 6c22ef52be70e11b6f3bcf0f672c96ce | | akasuna  | 1h029kh2lj11jmjxrg13k1c12b | 7128f587d88d6686974d6ef57c193628 | +----------+----------------------------+----------------------------------+

Salt 可以是任意字母、数字、或是字母或数字的组合,但必须是随机产生的,每个用户的 Salt 都不一样,用户注册的时候,数据库中存入的不是明文密码,也不是简单的对明文密码进行散列,而是 MD5( 明文密码 + Salt),也就是说:

MD5('123' + '1ck12b13k1jmjxrg1h0129h2lj') = '6c22ef52be70e11b6f3bcf0f672c96ce' MD5('456' + '1h029kh2lj11jmjxrg13k1c12b') = '7128f587d88d6686974d6ef57c193628'

由于加了 Salt,即便数据库泄露了,但是由于密码都是加了 Salt 之后的散列,坏人们的数据字典已经无法直接匹配,明文密码被破解出来的概率也大大降低。

是不是加了 Salt 之后就绝对安全了呢?淡然没有!坏人们还是可以他们数据字典中的密码,加上我们泄露数据库中的 Salt,然后散列,然后再匹配。但是由于我们的 Salt 是随机产生的,假如我们的用户数据表中有 30w 条数据,数据字典中有 600w 条数据,坏人们如果想要完全覆盖的坏,他们加上 Salt 后再散列的数据字典数据量就应该是 300000* 6000000 = 1800000000000,一万八千亿啊,干坏事的成本太高了吧。但是如果只是想破解某个用户的密码的话,只需为这 600w 条数据加上 Salt,然后散列匹配。可见 Salt 虽然大大提高了安全系数,但也并非绝对安全。

实际项目中,Salt 不一定要加在最前面或最后面,也可以插在中间嘛,也可以分开插入,也可以倒序,程序设计时可以灵活调整,都可以使破解的难度指数级增长。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏娱乐心理测试

Invalid prop: type check failed for prop "price". Expected String, got Number.

在谷歌浏览器上写Vue项目时,总会有很多警告,关键是红色的,非常刺眼,一片红好像是严重的错误,在有强迫症的程序员眼里非常之别扭,准备清除警告!

1822
来自专栏晨星先生的自留地

关于一次渗透引发的一个php木马的分析

4535
来自专栏逢魔安全实验室

SQL注入ByPass的一些小技巧

? 01 — 前言 SQL注入从古至今都是一个经久不衰的影响严重的高危漏洞,但是网络安全发展到现在,如果想通过SQL注入直接获取数据或者权限,多多少少都需要绕...

4139
来自专栏我杨某人的青春满是悔恨

Swift2网络操作和异常处理

相信写过Swift的人应该都知道Alamofire,它是AFNetworking的Swift版本,同一个作者写的。之前在项目中我也一直使用Alamofire,但...

1211
来自专栏Python爬虫与算法进阶

Scrapy中如何提高数据的插入速度

速度问题 最近工作中遇到这么一个问题,全站抓取时采用分布式:爬虫A与爬虫B,爬虫A给爬虫B喂饼,爬虫B由于各种原因运行的比较慢,达不到预期效果,所以必须对爬虫...

50511
来自专栏听雨堂

将一段复杂文本变成字符串的赋值语句

        因为需要在C#的代码中,写入一大段的js代码和网页代码,试验已经没有问题了。实现时却碰到一个小问题,就是大段的js和html代码,应该以什么方式...

1947
来自专栏友弟技术工作室

ElasticSearch入门实战1

1153
来自专栏FreeBuf

oclhashcat:离线hash密码破解工具官方文档(中文版)

无聊中,就把hashcat的官方文档稍微翻译了下,方便初学的朋友查看。至于oclhashcat,它是一个离线的hash密码破解工具,与hashcat不同,它支持...

9457
来自专栏一直在跳坑然后爬坑

RxJava2操作符之“Take”

最近我也在学习RxJava2,在网上找了好多文章来读,发现大多数都是说RxJava2和RxJava之间到底有什么区别的,每一个例子都要考虑RxJava里是怎么写...

1183
来自专栏烙馅饼喽的技术分享

本人有生以来的第一篇博客,嘿嘿,就发这个吧, 怎样在虚拟主机上使用Castle框架的ActiveRecord

        我在某个私人项目中使用了Castle 的 ActiveRecord.用起来那是真叫个爽,整个项目里楞是一句SQL语句都没有,嘿嘿。超级喜欢上了这...

2745

扫码关注云+社区

领取腾讯云代金券