密码泄路很疯狂，很多密码加密都使用了salt,如何安全的保存salt呢？

[etre]

如何安全的保存salt？存在其他地方，程序中等等？

[dndx]

个人理解，Salt似乎不需要什么特殊的保存措施。
Salt主要是想让彩虹表失效，它不能阻止密码被破解，但是应用了Salt后，哪怕是123456这样的简单密码，黑客也要从头跑起，从而大大增加破解难度。
所以Salt不需要安全的保存，直接写在程序里即可。

[master]

通上，当然还可以强化的就是对于不同帐号的密码用不同的salt，可以让破解不同的密码都需要重头跑

[clino]

@dndx 黑客如果能拿到数据库,能拿到代码的可能性也比较大,那在代码里不就能找到 salt 还有算法了

[summic]

安全的salt应该是每个用户单独的salt，而不是所有用户用固定的salt

看这篇文章

http://stackoverflow.com/questions/6340105/how-can-we-create-a-fairly-secure-password-hash-in-php

[skydark]

@clino 让黑客知道Salt也没关系，salt主要是为了防御彩虹表。
推荐一篇：http://hi.baidu.com/caoz/blog/item/edcc36d3f812891e3af3cf28.html

[CoX]

@clino 同意 @dndx 的说法， 加salt只是增加破解难度吧。
当然最好还是做好安全工作，如果能拿到代码，其实也不用看算法，在后台额外保存一份明文密码就可以了。

[skydark]

4# +1, 固定salt也是不安全的。

[CoX]

服务器被拿下了，什么算法都不安全

[dndx]

@clino 算法就用公开哈希算法，比如MD5，这个无所谓。比如123456加密后是e10adc3949ba59abbe56e057f20f883e
反查起来相当容易，但是假如加上一个叫做ewjpiojdewpoiqnjvcpowq的Salt，那么就变成
123456ewjpiojdewpoiqnjvcpowq，哈希值是：
2c4a3f980237b1b482f7c258637f9c41
这个哈希在任何彩虹表里都是查不到的。黑客如果特别想要破解密码，只能用你的Salt重建彩虹表，但是，更多黑客会选择直接放弃破解。

[clino]

@skydark 你推荐的这篇有提到:"只要你的加密算法是固定的，而且是黑客所能掌握的（比如固定salt被黑客知道），那么黑客跑一个常规密码档是非常快的，在这种情况下，你的用户库账号越多，黑客投入产出比越有价值，虽然没有cmd5这么庞大的碰撞库，但是用一天跑一个几千万乃至过亿常用密码的碰撞库，专门来对付你的数据库，也是很值得的事情，这种破解率，会很容易达到60%，有些朋友在微博反馈里说70%，大概也是这种类型"

[summic]

@dndx 知道了salt，黑客用现在已经泄漏的CSDN、天涯明文密码做字典，生成自己的彩虹表轻而易举

[kojp]

@summic

同意 ~~~

[skydark]

@clino 所以我补充了7楼。

[yyfearth]

@dndx @summic @kojp @clino 那么如果salt不固定，那么也得存到哪里，如果不存也要一个固定的生成算法，否则下次无法校验。
如果黑客拿到了全部算法和加密数据（如果salt保存，那么肯定也包括在内）
然后根据已经泄密的的数据，根据算法生成彩虹表应该也非常快。
那么除非用户的密码足够强劲，否则都没用啊~！

[yyfearth]

而且，如果是客户端的hash，不可能不透露hash算法和salt啊。

[cxh116]

@summic 每个用户一个salt, 假如你的字典有10万, 一个salt就要生成一次,那么10个密码就需要生成10,也就是100万
从某种意义上来讲,增加salt的长度,也可以提高安全性

[1212e]

如果能拿到你的密码,就一定能拿到你的salt.对吗?

[kongruxi]

可以考虑一下salt动态生成，比如是：数据库对应记录的id + 程序中的固定字符串

再扯出另一方面，建议用Bcrypt取代md5/sha

[cxh116]

@etre 问题忘记答了,一般一个用户对应一个salt,也就是说用户名增加一个salt字段就行了.

你看discuz的用户表设计,就有salt字段

http://www.henghome.com/dzx/20110121/pre_ucenter_members.html

[lwjef]

我也觉得MD5不适合加密 用来快速校验的吧

[SErHo]

类似WordPress的，直接将salt和加密的密码拼在一起存起来。

[yyfearth]

@kongruxi @cxh116 @SErHo 这样的话，泄露hash后的密码同时，salt也就必定泄露了。不过对抗彩虹表倒是有些用处，比固定的好。

[yyfearth]

但是，一个用户一个salt话，给验证带来了麻烦。

[9hills]

@yyfearth 如果每个用户一个salt的话，泄露就泄露了吧，有黑客蛋疼到给每个用户都跑一遍彩虹表么。。。


建议salt直上40位。然后抛弃md5,用sha1啥的。。。。

[yyfearth]

@kongruxi Bcrypt 确实不错，hash代价很高，就连服务器本身估计都够呛的，不要说爆破了。
@9hills 固定salt直接用binary keyfile。如果每个用户独立salt话，我觉得可以和hash后的长度相同，方便存储和分割。
觉得和hashed password合并在一起比较好，这样如果仅仅db被盗，还看不出个所以然来。
md5早就该放弃了，sha的话，sha512还是比较好的，256也不错，要求不高的话sha1也勉强。如果不追求性能的话，bcrypt挺好，我下次试试。

[bhuztez]

@9hills salt再长也挡不住人家拿着高频密码或者弱密码一个个试过来，试不出来就放弃的策略。

[9hills]

@yyfearth 当然你可以每个用户一个salt，然后再来一个固定salt。。
@bhuztez 每个用户一个salt啊，那得试到哪辈子去了。。

差不多就行了，黑客也是讲投入产出的，一天才能破一个用户，还必须的是弱密码。你当黑客是傻子么

[bhuztez]

@9hills 你也太低估现在的显卡了，有个估算表，你可以参考一下 http://golubev.com/gpuest.htm

[yyfearth]

@9hills 混合真是个好主意。sha512的话，sha512(512bit的随机salt+ps+1024Byte二进制keyfile) + 512bit的随机salt 得到1024bit的hash结果（sha256的话就是512bit）很恐怖啊~！
@bhuztez 说的一个个试，是可行的（比如就难123456去黑一个一般的论坛，绝对命中一大把，要是支付宝这种，估计没戏）
前提是：系统没有限制校验的次数而且速度比较快（在服务器端限制）
或者 得到了确切的算法，比如盗取了服务器脚本文件（php之类）或者反编译（java、.net之类）。这样就算是有单一salt，也无法阻止用字典爆破，除非用bcrypt这种非常“慢”的hash。

[9hills]

@bhuztez 注意我说的是一个用户一个salt。

黑客算出所有的 8位简单密码（纯数字小写字母） + salt 的彩虹表你觉得要花多长时间，你自己算一下吧

一个彩虹表只能用一次，下一个用户还得重新算一个

[9hills]

@yyfearth 我觉得网站也有责任，应该在本地就用js不允许使用弱密码。

8位以上，不允许纯数字，然后配合每个用户一个单独的40位salt，想安全再加一个固定salt

以目前的计算机水平，普通黑客就算拿到你的数据库，想算出来也基本不可能

[bhuztez]

@9hills 不是这个策略。比如CSDN存的是 SHA1(salt + password) ，有人拿到了 600W 帐号，对他来说，更好的策略是先算 600W帐号 SHA1(salt+'12345678') 而不需要分别计算彩虹表。

[9hills]

@bhuztez 本地用js禁止弱密码不就行了。8位以上带字母，算去吧

[yyfearth]

@9hills @bhuztez 就目前而言，每个用户不同salt基本上可以杜绝彩虹表的使用。但是要爆破还是可以的。
GPU的话，如果知道明确的算法，还是可以比较迅速的爆破出简单密码。
如果用上量子计算机的话，大部分密码都可以算出来。
不过总的来说，要同时盗取db和程序，还是比较难的。如果仅仅盗取db，猜不对算法，要爆破也不容易。

[dongbeta]

我们明文保存，你们继续……

[bhuztez]

@yyfearth 量子只是特别适合攻击RSA。对于别的类型的计算还没找到有效的算法。所以是另一个问题。

[yyfearth]

@bhuztez 独立salt，仅仅是对付彩虹表。
字典爆破是完全另外一种，只能靠加大hash计算量来阻止。但是这样的同时，程序的性能也大大降低。（但是相对影响肯定是爆破要大得多）
前面提到的bcrypt，就同时提供了这2种方法的解决方案。

[likuku]

我们明文保存，你们继续…… +10086

[likuku]

我们明文保存，你们继续…… +10086

[9hills]

@yyfearth 本地一定要做js弱密码验证。。。要不就和CSDN一样全是123456789.....

不知道有没有现成的js弱密码验证库可用，把这些都给禁了：
QWERTYUIOP
!@#$%^&*(
....

[bhuztez]

@yyfearth hash消耗计算能力过多，你就等着被DDoS吧

[yyfearth]

@dongbeta 对于用户而言，如果每个账号，密码都不一样，就算明文保存也不怕泄露。大不了从新生成一个。
我还用过用get明文发送用户名密码的系统呢~！（当然是玩玩）

[9hills]

@bhuztez 限制登录就好了，连续五次密码错误封ip 30min。

discuz都有这功能

[9hills]

@bhuztez 限制登录就好了，连续五次密码错误禁止ip登录 30min。

discuz都有这功能

[yyfearth]

@bhuztez @9hills 所以就要权衡。比如hash计算消耗的时间比原来直接用md5的慢上个几倍，效率并不会减低太多。但是对于破解者而言就效率就降低很多很多了。
限制次数也无法阻止大规模分布式的DDoS，不过相比没有来说会好很多。

[bhuztez]

@yyfearth 所以负责任的态度是只能选择不存，因为快的要被暴破，慢的要被DDoS

[9hills]

@bhuztez 不存密码？

世界上的事情都是权衡出来的，什么叫快的被暴破，慢的被DDOS

用上我上面说的那些方法，一般的黑客就已经无可奈何了。

你非要说假如大规模DDOS如何如何，假如别人用集群计算如何如何。。。当自己是Google啊，那么招人恨？

[yyfearth]

@bhuztez 如果啥时候可以发明不需要密码，而且又不麻烦的的authentication的方法，绝对是一次技术革命啊。
目前来说有指纹、面部、瞳孔。但是都不是很靠谱，而且都不如密码效果好。
我相信，如果读脑技术出现，可以解决这个问题。

[bhuztez]

@yyfearth 不能，因为设备可以伪造，哈哈哈

[yyfearth]

@9hills 别说，还真有不需要密码的网站，用cert数字证书，绝对比密码靠谱。不过相比之下使用更加麻烦。

[9hills]

@yyfearth 还有成本问题呢，数字证书怎么保证安全性，和银行一样搞USB key么？
USBkey的成本谁掏，做一个简单的网站，比如v2ex，然后上个USBkey，搞笑～

世上没有绝对的安全，只有相对的安全。假如都像@bhuztez这样抬杠，人类回到原始社会算了。

[bhuztez]

@9hills 因为很难权衡，随着时间推移安全的长度会逐渐变长，你得选择一个合适的策略，在合适的时候让用户换密码。

[dndx]

@yyfearth 对，农行的网银就是这样，插上USBKEY就有个Personal证书，拔掉就没了。
登录时选择证书就可以直接登录。

[yyfearth]

@bhuztez 如果把特定脑电波的pattern作为密码，由于数据量极大，而且可能很难模仿，相当于用非常非常长的密码，这样爆破几乎不可能了。（当然，那时候的计算机估计也可以到把我们目前所有密码爆破的能力）
用设备伪造前提是窃取了传输的信息或者在本地窃取（相当于keylogger），那是客户端和传输的问题了，那个对于服务器端就完全没辙。

[ofan]

脑波都出来了... 我来发动动波 ============>------

[bhuztez]

@9hills 安全策略本来就只能在确定你需要的安全等级后，相互challenge，排除了所有疑问之后才可以指定的。看看选个AES，到后面剩下几个选项在当时都没有哪怕不太明显的漏洞了，不还得继续相互challenge。

[yyfearth]

@dndx 但是就算是有证书，也往往还是要个密码，因为如果证书被盗，还有一层保障。除非2者一起被盗。
其实，现在大多增加安全性的方法，就是多种方法一起用。虽然麻烦了些，但是也更加要保障。比如手机的验证码，usbkey，数字证书，数字令牌，再加上传统的密码。
唉，扯太远了，睡觉去。

[yyfearth]

@9hills 弱密码验证库 可以直接用这次泄密的统计数据啊

[yyfearth]

@yyfearth 但是这样，有时候用户仅仅是想注册个号进去一下的话，就搞得用户很麻烦了。其实csdn那么多123456就是因为这个原因。

[clowwindy]

用户设置和修改密码时产生一个纯随机salt，明文保存。这样所有用户的密码hash就都不一样了，无法生成反查表。

[delectate]

用户名哈希值作为salt就挺好。
base64，sha1神码的都用上呗。
封ip不好，不如说：
1.验证码
2.三次机会。就算三次之后输对了，也提示错误。

[skywinger]

用非对称且相同明文每次加密密文都不同的RSA算法岂不是更好？

[bhuztez]

@skywinger RSA如何做到相同明文每次加密密文不同，表示不解

[xi4nyu]

@skywinger 能保证私钥的绝证安全么?

[skywinger]

@bhuztez 这就是非对称算法的特殊之处，有一些特定的随机因子，所以可能每次加密的密文不同，但是私钥能解的开。

[skywinger]

@xi4nyu 如果你采用硬件加密设备如HSM（硬件加密机）来存储加密密钥或是存储密钥的话，就非常安全了，而且是金融级别的安全性，银行都这么干的。