关于 md5 密码加密的一点小疑问

md5 不是加密算法，是 hash 算法。

在没有彩虹表，计算能力不强的年代，一个 md5 加密的确可以解决问题。
后来随着计算能力的提升，人们把常见的字符组合都拿去 md5 跑一遍，生成彩虹表，简单的 md5 就没有用了。
所以一般都需要加盐，并且每个用户的盐都不同。这样即使别人直接拿到了你的数据库数据，他也没办法根据彩虹表知道用户密码是啥了。

md5 不属于加密，因为散列函数的“值域”一定比它的“定义域”小，所以理论上是不可逆的。
但是因为有彩虹表这个东西，单纯用 MD5 已经不安全了，所以一般都会加盐处理。楼主可以看一下 PBKDF 函数的设计。

因为很多程序员只会 md5
不过新手能思考这些真不错了
遇到七八年开发经验的都认为 md5 是来加密的

参考 Linux 中 shadow 的存放，都是加了随机盐的

@qiayue
@jimzhong
像 cmd5 这种网站是骗人的还是真的可以破解，破解是靠彩虹表，还是它们真的计算能力强大，能够把密码算出来，我看很多人用了这类网站一段时间后可以破解出来（虽然收费）

首先，你要有“随手创个加密方式”的能力，我大学自学密码学一年多还是创造不出可靠的算法，怎么就随手了……

因为 md5 加密方式很完善，你自己创一个新的加密方式可能有漏洞。
因为有彩虹表，所以 md5 加密的时候必须要加盐，加盐后的安全性强于你自己创一个新的加密方式。
以前 wuyu 上面有篇文章详细解释了为什么不应该自己创建加密函数，可惜那个网站……

@binbinyouliiii 等你到了企业里就知道了 用简单密码的大有人在 很多系统密码都有个默认的 123456 什么 然后因为开发测试我们会借其他人的正式账户用
不改密码用 123456 的大有人在

@binbinyouliiii 我估计是用彩虹表，但是它的彩虹表规模会很大，以至于要收费。如果要验证用户密码还是推荐 PBKDF 。

加密密码段, 一般用 bcrypt 比较好. MD5 的算法已经被优化到极至了, 彩虹码加暴力破解很可能很快就算出.
bcrypt 算一个密码的时候是固定的, 暴力破解对它起不了作用.

salt 再加 salt

@otakustay 我也不了解算法什么的，我之前认为如果对原文做一些操作，比如原文第 2 个字符加一什么的，一般不知道的人也没法破解，算法有漏洞啥的更是不了解，原谅我小白

@jarlyyn 要是这样为何不直接用加密算法呢

@binbinyouliiii 如果感兴趣可以阅读一下 William Stallings 的《密码编码学与网络安全》。

@ma125125t 如果拖库加密密钥也很可能被对方知道。

@ma125125t

md5 并不是加密，还是取特征值。

加 salt 是为了让原始密码混淆，不容易被识别。

很多私人创建的加密算法，其实并不如一些主流的加密算法来得可靠。毕竟主流的加密算法在全球大范围的使用，如果有漏洞应该很快就会被发现了。自己创建的加密算法，除非很完美，否则不建议使用。

加盐，也就是你在用户的密码后面附加一个一定长度的字符串，有全网用同一个的，还有就是随机生成（记得一起存到数据库）每一个都不同。

然后对这个合成的密码进行 md5,一般会使用多次 md5 的方式，防止被彩虹表命中，或者被人撞库（应该没人会这样验证）


你用 md5 生成的，是没法算出原文的。

除非彩虹表。就是一个保存有原文和对应 md5 的表格，从里面查出来。而这个原文字符串也并不是机器穷苦出来的，而是从像 csdn 前期泄漏出的使用明文保存密码里面生成出来的，很多人的密码要么和 csdn 一样，要么就碰巧 csdn 这些库里就有一样的。就像 123456 这个密码，你会用，别人也会用。

别人黑掉你的服务器，你的加密算法也就到手，拿到你的加密算法密钥也是分分钟的事，所以使用加密算法不见得比 md5 好。

对用户密码加密，很多时候是为了保护用户的密码，而不是保护用户在你服务器的内容！

@jarlyyn 明白，使用 md5 或加盐的时候已经表明使用者不需要原文的任何信息，但希望结果是唯一值，是这个意思吧。

密码所在表添加一个字段 salt ，在登陆时通过用户名拿到 salt 再和传上来的密码进行拼接后求 MD5 ，再和数据库的 MD5 值比较.

加一个随机 salt

@ma125125t

结果也不是唯一值。

而是碰撞的概率足够小。

@jarlyyn 还有一个问题，没拿到盐的情况下，有办法获取加过盐的密码的散列值的原文吗？如果没办法，是否没必要加两次盐呢，或者说加两次盐的目的是防止第一个盐被获取的情况下进行再保护呢。不过盐又怎么会拿到呢，一般盐放在数据库中，拿到盐的时候已经拿到密码了吧？不知道我的理解有没有问题。

md5 的解密成本就是 cmd5 的价格

要发明一个 Hash 算法，你得先去证明它是 Hash 算法。

自己写的加密算法有一个可怕的地方在于，网站得漏洞让加密代码爆出的可能性。
想想就觉得可怕了。你在某网站得密码，可以解密出来的……
MD5 即使结合彩虹表，也不表示所有密码是由对应的。所以其实加点盐， MD5 目前足够使用的了。

@ma125125t

盐和密码（特征码）是放在一起的。加盐就是为了数据库被拖库的情况下保证安全。

一次加盐和两次加盐的安全性差不多。

我只是为了以后可以本地存 hash 代替密码

转乌云的一篇很赞文章
https://jiji262.github.io/wooyun_articles/drops/%E5%8A%A0%E7%9B%90hash%E4%BF%9D%E5%AD%98%E5%AF%86%E7%A0%81%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F.html

核心观点：
1 ，不要自创 hash 算法
2 ，加盐，而且盐长度足够，至少要和 hash 输出一样长
3 ，不要重复使用盐

科班出身是多么重要…

额，好多人似乎没有学过密码学。。。

最后不建议自造算法，建议多看看书。

加盐,以及 hash 次数

加盐；加随机盐

@xi2008wang 看的好爽

@binbinyouliiii 你“加密”（加引号，因为正确的说法是哈希）的意义在于把你的代码 /算法和数据都交给别人的情况下，别人依然无法轻易获得你用户的密码。为什么要把代码和数据给别人？因为你有信心永远不被黑么。。。


然后再来说一些上面已经有人提到的内容。彩虹表的原理是什么？因为 md5 的结果是确定的，也就是说对于 A 输入，它得出的结果一定是 A'，那么我就可以预先计算好。这样子当你给我一个 md5 的结果时，我就能反向找出它对应的明文是什么。而且在实际上，很多人用的密码都很常见，所以很容易就被找到了（也就是破解了）

然后就有了加盐的概念，既然用户自己的密码很容易被破解，那么我就在用户的密码上增加点什么。考虑到彩虹表的原理是预先算好，所以应对的方法很简单，我使用户的密码变得很长（例如在最后加上个 32 位字符串）。← 这也是为什么你提出的『用户密码第二位+1 』这种方案没有意义，在知道你的算法后，别人的计算量并没有提高

然后之所以不要重复用盐， 是因为如果你对于所有用户的盐值都一样，那么入侵者就可以针对你的盐值，专门打造一份彩虹表来进行破解。而如果每个用户的盐值都不一样，那么他破解的代价将高很多很多（ 不存在绝对安全的算法，我们能做的就是在自己能够承受的情况下，尽可能提高入侵者的成本）

最后说下换算法以及加 hash 次数。 md5 之所以以前没问题，现在不行了的原因是计算力的不断提高。所以首先增加 hash 的次数这种做法是有意义的，因为它会增加彩虹表生成的时间。然而这种意义不大。。。因为计算力依然在继续提高。。。但这个思路是完全正确的，例如 bcrypt 或者 pbkdf2 都是这种思路。假如每次函数调用增加到半秒，对于正常的业务来说影响不大（只需要在登录时验证），但对于彩虹表来说，哪怕只计算 8 位的纯数字就需要 10,000,000*.5/86400=57.87 天了。别觉得这个时间好像很短，因为这只是 8 位纯数字，换成 8 位的数字+大小写字母就是 62^8*0.5/86400/365=3461759 年了。。。而且配合上面说的不要重复用盐，对于每个用户都重新计算彩虹表，这个代价就更加的大了。。。

md5 什么时候是加密的
觉得至少也要 sha1 吧

@Halry sha 几都不是加密的

@lance6716 科班也没啥用吧..你读大学的时候有教这个...起码我大学老师..也是把 md5 管加密..我去吐槽他的时候.还不鸟我..

@wy315700 我的意思是 md5 是 hash 算法,根本没有加密功能,因为是不可逆转的.

@Halry 加密举个 aes 吧...sha 也是散列算法..

@youxiachai 看上一楼,表达错误,sorry

@youxiachai
@Halry
但是 SHA 算法其实是一个固定密钥的块加密算法

@Halry sha1 可逆？

md5 来做 Bloom filter 的散列函数不错 (还记得当年实验室开周技术分享的时候 因为说了 md5 是加密算法 被学长嘲笑的无地自容)

@youxiachai 学通信的，好多门课都会讲加密和消息摘要

这叫非对称加密

@fyibmsd 第一次听说非对称加密这么解释的

@Halry

其实并不是说 Hash 不能用来做密码“加密”，只是说很多 Hash 算法太快了。密码的 Hash 算法需要能控制 Hash 计算的速度，原字符串输入进去之后，必须使用大于 N 的时间才能算出对应的 Hash ，这样才可以保证密码在 N 年内不太可能被破解出来。

直接用 MD5 、 SHA1 的问题是，如果 Hash 拿到手，几分钟撞出一个，对于关键人物（比如各种 SSL 证书）来说跟没 Hash 过的完全没有区别。

TL; DR 直接用 bcrypt (如果你担心基于 ASIC 或者 FPGA 的硬件密码破解，用 scrypt ）

@lance6716 额，我学 java 的，老师从来没提起过 md5 啥的，难道别的老师都教这个嘛

http://webcache.googleusercontent.com/search?q=cache:ezsTSZ3IZUEJ:blog.jobbole.com/87058/+&cd=1&hl=zh-CN&ct=clnk (源站打不开 贴快照了)
http://coolshell.cn/articles/2078.html

用 bcrypt 、用 bcrypt 、用 bcrypt
别用 MD5 、 SHA1 、 SHA256 、 SHA512 、 SHA-3 等“加密”算法

md5(md5(pwd)+$%^*&) ，欢迎来解

还好我学过密码学，你可以百度一下，山大王小云

md5 、 sha1 这类算法都是单向哈希算法，不算加密。 bcrypt 是专门为密码存储而设计的算法。一般把密码 MD5 后的哈希值再用一次 bcrypt 加密，已经不可能被破解了。

@haozibi 哈哈，我一开始看成山大王 小云 了 shan dai wang xiaoyun

@binbinyouliiii
额，学校里不都是教计算机网络的时候顺带教一下 java 的吗？ java 这么简单，还有单独的课程么？
我念书的时候，只有 C/C++有单独的课程。

我上学的时候密码学虽然是选修，但是属于预订的默认课程。

@wy315700 虽然多了一个向量配置（固定密钥），但依然不是加密算法。本质上还是属于摘要算法。
@fyibmsd 非对称加密。。。你脑洞太大了吧。。。公私钥分别是啥？

@jimzhong 真的可以破解。 md5 ， sha1 什么的都是 hash(摘要)算法，是不可逆的，不是加密。

有了彩虹表是不安全，所以密码不要设置为'123456'这种简单的密码。但程序上可以加盐，比如 md5(md5('123456') + 'abc')。当然盐也不能很简单。设置可以每个用户不同的盐。

@damean 大神，这么厉害，“ Java 这么简单”
话说 v 友们都对 java 很排斥吗

@binbinyouliiii java 真算是简单的。
但是“排斥”是什么鬼？你是怎么脑补出“排斥”的？“简单”==“排斥”？

@damean 不是，我之前再 v 站看过几篇帖子，很多人对 java 都以嘲笑的态度来说的

"0e31a" == 0
"0e1ba" == 0

"0e31a" =? "0e1ba"

直接上 SHA512

你说的应该是如何存储密码以达到验证用户登录，而不是密码加密

最不安全的是密码存明文，一般情况下没事，但一旦数据库被拖库，然后所有用户的密码都被知道。

所以使用正确的方式存储密码可以尽量减少上述情况带来的灾难。

首先，不应该使用 SHA-0 （ md5 ）， SHA-0 的位数太短，已经不安全， SHA-1 目前都被认为不足够安全了，所以应该使用 SHA-256 或更高位数的， SHA-512 感觉没必要。

应该这样存储，用户一个表中，应该包含这两样，都要存储

salt = rand() # 一个随机数，位数最好要长于 256 个比特
password = hash( password + salt )

这样在验证用户的时候，读取这两个字段验证：

if( hash( password + salt ) == hash( input_password + salt ) ){
// 登录成功
}


关于已知数据库后破解原密码难度（假设 hash 算法达到了 hash 算法应该达到的安全性）：

1 只存储 hash ：

直接使用当前算法的彩虹表，（几乎）可以破解所有用户的原密码

2 存储加一样的盐的 hash ：

可以针对当前的盐重新生成彩虹表，然后就能破解所有用户的原密码，难度远大于前者

3 存储一个随机的盐和加随机的盐的 hash ：

必须针对每个用户单独破解，破解难度所有用户原密码难度直升至（基本上）不可能，难度远大于前者

随手创个加密方式？不是不可以，但是绝对不要这样做！

目前使用的加密方法都是经过大量的实际使用而确认这是个“好”的加密算法

几乎没有人会随手创个“好”的加密方式，如果你学过密码学，一些加密函数的实现，那么就再也不会想要自己创加密方式了。

一般不用 md5 都用 sha 并加盐了，不开玩笑

哈希算法未必能散列的很好，谨慎一点好

md5 都是什么年代的玩意儿了，也就在不重视用户信息安全的中国大陆开发者里头算是自以为比明文存储强一些的 Best Practice 。
单纯的 hash function 就算是 SHA3-512 也不应该作为 KDF 使用，即使加 nonce as salt 也不安全，这应该是普通开发者应该有的常识。说什么 MD5 不够安全应该用 SHA 系列的也只是五十步笑百步而已。
安全界现在的共识是在 GPGPU 时代连 PBKDF2 、 bcrypt 这种都不能视为安全的 KDF 。当前得到较广泛使用的 GPGPU-proof 的方案是 scrypt ，然而依然有 ASIC 可以搞它。
目前最安全的方案应该是 Argon2 ，只是对它的 Cryptanalysis 还不够多，不建议在生产系统中用。
简单的说：
安全性&计算开销： Argon2 > scrypt > bcrypt > PBKDF2 > hash with salt > plain hash > plaintext
没有历史包袱的新系统最低限度应该用 PBKDF2 ， cost factor 还要设得尽量大些反 rainbow table 。如果能用 scrypt 尽量上 scrypt 。
认为普通 hash function 就能当 KDF 用的都应该去补习一下密码学导论，而直接把用户明文密码存储入库的蠢货应该枪毙。