1
dndx 2011-12-29 16:48:52 +08:00
个人理解,Salt似乎不需要什么特殊的保存措施。
Salt主要是想让彩虹表失效,它不能阻止密码被破解,但是应用了Salt后,哪怕是123456这样的简单密码,黑客也要从头跑起,从而大大增加破解难度。 所以Salt不需要安全的保存,直接写在程序里即可。 |
2
master 2011-12-29 16:50:44 +08:00
通上,当然还可以强化的就是对于不同帐号的密码用不同的salt,可以让破解不同的密码都需要重头跑
|
4
summic 2011-12-29 16:57:14 +08:00
安全的salt应该是每个用户单独的salt,而不是所有用户用固定的salt
看这篇文章 http://stackoverflow.com/questions/6340105/how-can-we-create-a-fairly-secure-password-hash-in-php |
5
skydark 2011-12-29 16:58:55 +08:00
@clino 让黑客知道Salt也没关系,salt主要是为了防御彩虹表。
推荐一篇:http://hi.baidu.com/caoz/blog/item/edcc36d3f812891e3af3cf28.html |
6
CoX 2011-12-29 16:59:38 +08:00
|
7
skydark 2011-12-29 17:00:17 +08:00
4# +1, 固定salt也是不安全的。
|
8
CoX 2011-12-29 17:07:39 +08:00
服务器被拿下了,什么算法都不安全
|
9
dndx 2011-12-29 17:08:07 +08:00
@clino 算法就用公开哈希算法,比如MD5,这个无所谓。比如123456加密后是e10adc3949ba59abbe56e057f20f883e
反查起来相当容易,但是假如加上一个叫做ewjpiojdewpoiqnjvcpowq的Salt,那么就变成 123456ewjpiojdewpoiqnjvcpowq,哈希值是: 2c4a3f980237b1b482f7c258637f9c41 这个哈希在任何彩虹表里都是查不到的。黑客如果特别想要破解密码,只能用你的Salt重建彩虹表,但是,更多黑客会选择直接放弃破解。 |
10
clino 2011-12-29 17:16:54 +08:00
@skydark 你推荐的这篇有提到:"只要你的加密算法是固定的,而且是黑客所能掌握的(比如固定salt被黑客知道),那么黑客跑一个常规密码档是非常快的,在这种情况下,你的用户库账号越多,黑客投入产出比越有价值,虽然没有cmd5这么庞大的碰撞库,但是用一天跑一个几千万乃至过亿常用密码的碰撞库,专门来对付你的数据库,也是很值得的事情,这种破解率,会很容易达到60%,有些朋友在微博反馈里说70%,大概也是这种类型"
|
14
yyfearth 2011-12-29 18:46:12 +08:00
|
15
yyfearth 2011-12-29 18:47:28 +08:00
而且,如果是客户端的hash,不可能不透露hash算法和salt啊。
|
16
cxh116 2011-12-29 18:51:00 +08:00
@summic 每个用户一个salt, 假如你的字典有10万, 一个salt就要生成一次,那么10个密码就需要生成10,也就是100万
从某种意义上来讲,增加salt的长度,也可以提高安全性 |
17
1212e 2011-12-29 18:55:39 +08:00
如果能拿到你的密码,就一定能拿到你的salt.对吗?
|
18
kongruxi 2011-12-29 18:58:45 +08:00
可以考虑一下salt动态生成,比如是:数据库对应记录的id + 程序中的固定字符串
再扯出另一方面,建议用Bcrypt取代md5/sha |
19
cxh116 2011-12-29 19:00:03 +08:00
@etre 问题忘记答了,一般一个用户对应一个salt,也就是说用户名增加一个salt字段就行了.
你看discuz的用户表设计,就有salt字段 http://www.henghome.com/dzx/20110121/pre_ucenter_members.html |
20
lwjef 2011-12-29 19:04:08 +08:00
我也觉得MD5不适合加密 用来快速校验的吧
|
21
SErHo 2011-12-29 19:16:54 +08:00
类似WordPress的,直接将salt和加密的密码拼在一起存起来。
|
22
yyfearth 2011-12-29 19:46:08 +08:00
|
23
yyfearth 2011-12-29 19:48:09 +08:00
但是,一个用户一个salt话,给验证带来了麻烦。
|
24
9hills 2011-12-29 19:50:51 +08:00
|
25
yyfearth 2011-12-29 20:10:07 +08:00
|
27
9hills 2011-12-29 20:22:09 +08:00
|
28
bhuztez 2011-12-29 20:28:22 +08:00
@9hills 你也太低估现在的显卡了,有个估算表,你可以参考一下 http://golubev.com/gpuest.htm
|
29
yyfearth 2011-12-29 20:34:51 +08:00
@9hills 混合真是个好主意。sha512的话,sha512(512bit的随机salt+ps+1024Byte二进制keyfile) + 512bit的随机salt 得到1024bit的hash结果(sha256的话就是512bit)很恐怖啊~!
@bhuztez 说的一个个试,是可行的(比如就难123456去黑一个一般的论坛,绝对命中一大把,要是支付宝这种,估计没戏) 前提是:系统没有限制校验的次数而且速度比较快(在服务器端限制) 或者 得到了确切的算法,比如盗取了服务器脚本文件(php之类)或者反编译(java、.net之类)。这样就算是有单一salt,也无法阻止用字典爆破,除非用bcrypt这种非常“慢”的hash。 |
30
9hills 2011-12-29 20:36:38 +08:00
@bhuztez 注意我说的是一个用户一个salt。
黑客算出所有的 8位简单密码(纯数字小写字母) + salt 的彩虹表你觉得要花多长时间,你自己算一下吧 一个彩虹表只能用一次,下一个用户还得重新算一个 |
31
9hills 2011-12-29 20:39:38 +08:00
@yyfearth 我觉得网站也有责任,应该在本地就用js不允许使用弱密码。
8位以上,不允许纯数字,然后配合每个用户一个单独的40位salt,想安全再加一个固定salt 以目前的计算机水平,普通黑客就算拿到你的数据库,想算出来也基本不可能 |
32
bhuztez 2011-12-29 20:40:07 +08:00
@9hills 不是这个策略。比如CSDN存的是 SHA1(salt + password) ,有人拿到了 600W 帐号,对他来说,更好的策略是先算 600W帐号 SHA1(salt+'12345678') 而不需要分别计算彩虹表。
|
34
yyfearth 2011-12-29 20:43:56 +08:00
|
35
dongbeta 2011-12-29 20:45:45 +08:00
我们明文保存,你们继续……
|
37
yyfearth 2011-12-29 20:47:16 +08:00
@bhuztez 独立salt,仅仅是对付彩虹表。
字典爆破是完全另外一种,只能靠加大hash计算量来阻止。但是这样的同时,程序的性能也大大降低。(但是相对影响肯定是爆破要大得多) 前面提到的bcrypt,就同时提供了这2种方法的解决方案。 |
38
likuku 2011-12-29 20:47:17 +08:00
我们明文保存,你们继续…… +10086
|
39
likuku 2011-12-29 20:47:48 +08:00
我们明文保存,你们继续…… +10086
|
40
9hills 2011-12-29 20:48:07 +08:00
@yyfearth 本地一定要做js弱密码验证。。。要不就和CSDN一样全是123456789.....
不知道有没有现成的js弱密码验证库可用,把这些都给禁了: QWERTYUIOP !@#$%^&*( .... |
42
yyfearth 2011-12-29 20:50:06 +08:00
@dongbeta 对于用户而言,如果每个账号,密码都不一样,就算明文保存也不怕泄露。大不了从新生成一个。
我还用过用get明文发送用户名密码的系统呢~!(当然是玩玩) |
45
yyfearth 2011-12-29 20:58:32 +08:00
|
47
9hills 2011-12-29 21:04:41 +08:00
@bhuztez 不存密码?
世界上的事情都是权衡出来的,什么叫快的被暴破,慢的被DDOS 用上我上面说的那些方法,一般的黑客就已经无可奈何了。 你非要说假如大规模DDOS如何如何,假如别人用集群计算如何如何。。。当自己是Google啊,那么招人恨? |
48
yyfearth 2011-12-29 21:05:10 +08:00
@bhuztez 如果啥时候可以发明不需要密码,而且又不麻烦的的authentication的方法,绝对是一次技术革命啊。
目前来说有指纹、面部、瞳孔。但是都不是很靠谱,而且都不如密码效果好。 我相信,如果读脑技术出现,可以解决这个问题。 |
51
9hills 2011-12-29 21:09:54 +08:00
|
53
dndx 2011-12-29 21:11:28 +08:00
@yyfearth 对,农行的网银就是这样,插上USBKEY就有个Personal证书,拔掉就没了。
登录时选择证书就可以直接登录。 |
54
yyfearth 2011-12-29 21:12:52 +08:00
@bhuztez 如果把特定脑电波的pattern作为密码,由于数据量极大,而且可能很难模仿,相当于用非常非常长的密码,这样爆破几乎不可能了。(当然,那时候的计算机估计也可以到把我们目前所有密码爆破的能力)
用设备伪造前提是窃取了传输的信息或者在本地窃取(相当于keylogger),那是客户端和传输的问题了,那个对于服务器端就完全没辙。 |
55
ofan 2011-12-29 21:13:54 +08:00
脑波都出来了... 我来发动动波 ============>------
|
56
bhuztez 2011-12-29 21:14:55 +08:00
@9hills 安全策略本来就只能在确定你需要的安全等级后,相互challenge,排除了所有疑问之后才可以指定的。看看选个AES,到后面剩下几个选项在当时都没有哪怕不太明显的漏洞了,不还得继续相互challenge。
|
57
yyfearth 2011-12-29 21:16:14 +08:00
@dndx 但是就算是有证书,也往往还是要个密码,因为如果证书被盗,还有一层保障。除非2者一起被盗。
其实,现在大多增加安全性的方法,就是多种方法一起用。虽然麻烦了些,但是也更加要保障。比如手机的验证码,usbkey,数字证书,数字令牌,再加上传统的密码。 唉,扯太远了,睡觉去。 |
59
yyfearth 2011-12-29 21:20:12 +08:00
@yyfearth 但是这样,有时候用户仅仅是想注册个号进去一下的话,就搞得用户很麻烦了。其实csdn那么多123456就是因为这个原因。
|
60
clowwindy 2011-12-29 21:22:24 +08:00
用户设置和修改密码时产生一个纯随机salt,明文保存。这样所有用户的密码hash就都不一样了,无法生成反查表。
|
61
delectate 2011-12-29 21:23:10 +08:00
用户名哈希值作为salt就挺好。
base64,sha1神码的都用上呗。 封ip不好,不如说: 1.验证码 2.三次机会。就算三次之后输对了,也提示错误。 |
62
skywinger 2011-12-29 21:53:23 +08:00
用非对称且相同明文每次加密密文都不同的RSA算法岂不是更好?
|