网站搭建定制,网页设计需要学什么编程,o2o网站开发公司,云南网站开发公司找哪家盐#xff08;Salt#xff09; 在密码学中#xff0c;是指通过在密码任意固定位置插入特定的字符串#xff0c;让散列后的结果和使用原始密码的散列结果不相符#xff0c;这种过程称之为“加盐”。 以上这句话是维基百科上对于 Salt 的定义#xff0c;但是仅凭这句话还是… 盐Salt 在密码学中是指通过在密码任意固定位置插入特定的字符串让散列后的结果和使用原始密码的散列结果不相符这种过程称之为“加盐”。 以上这句话是维基百科上对于 Salt 的定义但是仅凭这句话还是很难理解什么叫 Salt以及它究竟起到什么作用。 第一代密码 早期的软件系统或者互联网应用数据库中设计用户表的时候大致是这样的结构
mysql desc User;
---------------------------------------------------
| Field | Type | Null | Key | Default | Extra |
---------------------------------------------------
| UserName | varchar(50) | NO | | | |
| PassWord | varchar(150) | NO | | | |
---------------------------------------------------数据存储形式如下
mysql select * from User;
--------------------
| UserName | PassWord |
--------------------
| lichao | 123 |
| akasuna | 456 |
--------------------主要的关键字段就是这么两个一个是登陆时的用户名对应的一个密码而且那个时候的用户名是明文存储的如果你登陆时用户名是 123那么数据库里存的就是 123。这种设计思路非常简单但是缺陷也非常明显数据库一旦泄露那么所有用户名和密码都会泄露后果非常严重。参见《CSDN 详解 600 万用户密码泄露始末》。 第二代密码 为了规避第一代密码设计的缺陷聪明的人在数据库中不在存储明文密码转而存储加密后的密码典型的加密算法是 MD5 和 SHA1其数据表大致是这样设计的
mysql desc User;
---------------------------------------------------
| Field | Type | Null | Key | Default | Extra |
---------------------------------------------------
| UserName | varchar(50) | NO | | | |
| PwdHash | char(32) | NO | | | |
---------------------------------------------------数据存储形式如下
mysql select * from User;
--------------------------------------------
| UserName | PwdHash |
--------------------------------------------
| lichao | 202cb962ac59075b964b07152d234b70 |
| akasuna | 250cf8b51c773f3f8dc8b4be867a9a02 |
--------------------------------------------假如你设置的密码是 123那么数据库中存储的就是 202cb962ac59075b964b07152d234b70 或 40bd001563085fc35165329ea1ff5c5ecbdbbeef。当用户登陆的时候会把用户输入的密码执行 MD5或者 SHA1后再和数据库就行对比判断用户身份是否合法这种加密算法称为散列。 严格地说这种算法不能算是加密因为理论上来说它不能被解密。所以即使数据库丢失了但是由于数据库里的密码都是密文根本无法判断用户的原始密码所以后果也不算太严重。 第三代密码 本来第二代密码设计方法已经很不错了只要你密码设置得稍微复杂一点就几乎没有被破解的可能性。但是如果你的密码设置得不够复杂被破解出来的可能性还是比较大的。 好事者收集常用的密码然后对他们执行 MD5 或者 SHA1然后做成一个数据量非常庞大的数据字典然后对泄露的数据库中的密码就行对比如果你的原始密码很不幸的被包含在这个数据字典中那么花不了多长时间就能把你的原始密码匹配出来。这个数据字典很容易收集CSDN 泄露的那 600w 个密码就是很好的原始素材。 于是第三代密码设计方法诞生用户表中多了一个字段
mysql desc User;
--------------------------------------------------
| Field | Type | Null | Key | Default | Extra |
--------------------------------------------------
| UserName | varchar(50) | NO | | | |
| Salt | char(50) | NO | | | |
| PwdHash | char(32) | NO | | | |
--------------------------------------------------数据存储形式如下
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 不一定要加在最前面或最后面也可以插在中间嘛也可以分开插入也可以倒序程序设计时可以灵活调整都可以使破解的难度指数级增长。 PS文中所谓第一、二、三代密码的称呼是我自己 YY 的。 From:http://www.libuchao.com/2013/07/05/password-salt
