有关密码的一些思考

2014-12-25 14:47:57 +08:00
 LukeXuan
今日看到12306被脱裤后许多v友都哭天喊地地去改密码…(还好我没用过12306…
作为高中生没收入用不起1password 就构思了一种廉价的防脱裤的密码方案:
一个唯一的master password
一个每个账户独立的salt(为了方便记忆可以是这个账户的应用名 如alipay tmall)
然后用md5或者其他不可逆的hash算法算出该账户的密码

大概唯一的问题就是每次计算出密码比较麻烦吧…

还有这种方案会不会有安全问题,比如:
知道了一个hash值和它的salt值 可以求出相同master password但另外一个salt的hash值?
3914 次点击
所在节点    问与答
38 条回复
Layne
2014-12-25 14:52:43 +08:00
搜索一下花密
wy315700
2014-12-25 14:55:15 +08:00
现在的问题不在这里,你密码弱的话,salt也没用。
LukeXuan
2014-12-25 14:56:07 +08:00
@Layne 好像是一样的idea 受教了
LukeXuan
2014-12-25 14:58:03 +08:00
@wy315700 我现在讨论的不是强弱的问题啦 是用于应对以csdn为首的明文存储厂商的
Layne
2014-12-25 15:02:20 +08:00
@wy315700 我记得在github上有源码,有兴趣的话可以研究一下。
我个别几个有可能需要在公共机器上登录的帐号的密码是通过花密生成的。
大多数不会在不是自己的机器上登录的帐号都是用1Password生成和存储密码。
wy315700
2014-12-25 15:09:11 +08:00
@LukeXuan 我的意思是,你这种方法大家都在用了,是防止不了脱裤的。


@Layne 这种方法本质上不能增加安全性,安全性还是由原始的密码决定,只不过解密的时候多了个花密的解密而已,我记得密码学理论里有这么一句,多次hash不能增加安全性的。
LukeXuan
2014-12-25 15:27:39 +08:00
@wy315700
1. 我所说的pass, salt, hash是用户端自己计算的部分 而不是数据库中存储密码时进行的操作
2. 我所讨论问题的前提是该用户有足够的安全意识 亦即 如果 他不进行这个操作 数据库使用非对称加密后的密文存储密码 即使数据库被脱裤 也无法在可承受的时间代价内通过获得的密文密码 破解出他的明文密码
3. 而这种方法目的在于把脱裤的影响限制在被脱裤的服务内 而不导致其他服务的密码被获取
wy315700
2014-12-25 15:32:22 +08:00
@LukeXuan 你这个本质上和一个长密码效果是一样的,只不过这个长密码是你用hash计算出来的,
破解的时候,我不需要破解pass和salt,而只需要知道你本地hash的结果就可以登录到服务器了。
LukeXuan
2014-12-25 15:34:02 +08:00
@wy315700
防止脱裤不是用户能控制的 但是我认为这种方法可以控制被脱裤后的对其他账户影响 同时尽量减少记忆密码的麻烦
LukeXuan
2014-12-25 15:34:39 +08:00
@wy315700 但是你只知道12306的密码而已 不能知道我alipay的密码
wy315700
2014-12-25 15:45:47 +08:00
@LukeXuan 这么做 和你在12306设置一个密码,在alipay设置另一个密码 有什么区别呢。
nealfeng
2014-12-25 15:48:17 +08:00
可以用keepass,开源的。虽然不是特别好。
USCONAN
2014-12-25 15:51:54 +08:00
目前我是已經逐漸轉到 1Password,
在這之前我的密碼是人肉計算,因為以前沒有特別方便的密碼管理的方式,特別是智能手機以前,所以人肉算法可以在保證一定程度的密碼複雜度的同時還能保證不會忘記密碼。

計算過程大致是這樣
根據註冊的服務,然後用美國記電話號碼的習慣反轉成數字,隔字換符後加入定期修改的固定字元。

例如: 註冊 google.com,取 google,之後反轉為 466453,然後隔字 Shift 換符變成 4^6$5#,
最後頭尾加入固定的字元變成 ***4^6$5#*** 這種造型。(固定字元會定期修改).
daiv
2014-12-25 15:52:13 +08:00
@nealfeng keepass 我也在用!
LukeXuan
2014-12-25 15:54:28 +08:00
@wy315700 没区别 只是为了减少记忆高强度密码而已 毕竟不是那么好背的
invite
2014-12-25 15:57:16 +08:00
直接上加密机,密码都在加密机里。

所有认证通过接口通讯,没有任何数据库操作。
Earthman
2014-12-25 15:57:22 +08:00
@wy315700 多次hash不能增加安全性的,这个是什么原理,能否简单明了地解释一下
imn1
2014-12-25 15:57:55 +08:00
你这个很多人想过,也包括我(我就自写了一个类似工具),最关键一点是每个人(每个客户端)的算法都要不同才行,否则知道算法的话,破主密码就所有站全破了
LukeXuan
2014-12-25 16:09:14 +08:00
@imn1 大概破主密码难度和主密码的强度一致的吧 所以在这个层面上做好大概就行了?
wy315700
2014-12-25 16:28:00 +08:00
@Earthman
因为hash不是加密,hash只是一个单向映射函数。

我说的其实是单纯多次hash不能增加安全性,很多密码学教材里都有写,但是没写原因,我想了一下

b = hash(a)
c = hash(hash(a))

b和c的安全性是一样的

如果hash不可逆向,那么唯一的办法就是暴力搜索a,只不过一个要做一次运算,一个要做两次运算。

如果hash可逆,那么 a可以推出b,同理b也可以推出c



如果要用salt,建议采用安全标准里的hmac,而不是大部分系统采用的 hash(pass + salt)的方法

http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/156602

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX