1
Kid 2011-12-22 04:59:51 +08:00
这是个好思路。
其实可以预置一些网站的密码要求…… |
2
zythum 2011-12-22 05:05:13 +08:00
原来是孙燕姿大大。不过这样用着不方便。每次登陆都要过来算一编。
|
3
windhunter 2011-12-22 05:17:35 +08:00
这个思路不错!
|
4
CupTools 2011-12-22 06:07:36 +08:00
crypt可以完成你的愿望
|
5
frittle 2011-12-22 08:27:06 +08:00
嗯 直接使用Javascript让人有安全感。但使用起来确实不方便,也不可能把每个生成的密码牢记。
个人需要生成密码时都直接用chrome里的LastPass扩展,然后就顺便保存在LastPass上了。 |
6
arzusyume 2011-12-22 09:11:04 +08:00
我觉得这个做成浏览器扩展不错,鉴别码可以用域名
|
7
likuku 2011-12-22 09:40:07 +08:00
不加盐就一样不安全。
|
8
sharmy 2011-12-22 09:41:37 +08:00
。。我昨天还在想写个类似的东西
|
9
bhuztez 2011-12-22 09:48:36 +08:00
|
10
jenshan 2011-12-22 09:55:54 +08:00
正在和同学做这类的一个软件,也算是有个作品,结果还没做完,楼主就拿出来了
|
11
summic 2011-12-22 10:50:02 +08:00
lz的有盐
|
12
Sunyanzi OP @frittle 为什么要记生成的密码呢 ..?
只要所有填写的东西都一样 ... 最后生成的密码必定也是一样的 ... 你可以只记非常简单的主密码如 123456 ... 然后每次都复制转化后的密码填到网站上就好 ... @likuku @bhuztez 您二位是如何得知我没有盐化密码或者没有使用基于 HMAC 的算法呢 ..? 我真的很好奇这个结论是如何得出的 ... 我在主贴里写 MD5 和 SHA-512 是具体描述 ... 毕竟 v2ex 是技术论坛 ... 不然我写 使用某两种基于 HMAC 的算法 ... 也许会更利于理解一些 ..? 另外说 ... 虽然我的算法里面有用到盐 ... 但其实凭心而论 ... 我不觉得这么做在当前这个场景下对提升安全性有什么帮助 ... 其实除了看起来专业之外 ... 我根本完全想不出这么做有什么意义 ... 密码保存的时候盐化的目的是使同一个明文被摘要之后生成的文字不相同 ... 而在我这个应用里 ... 只要你填写的东西都一样 ... 那么生成的密码也绝对是一样的 ... 这是系统立足的根本 ... 稳定性的保证 ... 我想我大概是没 catch 到您的思路 ... 您觉得盐化在这里会对提升安全性有怎样的帮助呢 ..? |
13
Showfom 2011-12-22 13:06:41 +08:00
感谢楼主的分享~
|
15
Sunyanzi OP @frittle 假如 lastpass 的数据库一丢 ... 我只是说假如 ...
你的所有密码哪怕随机生成的再复杂 ... 也全部以明文的形式暴露在别人面前了 ... 这就是我为什么不相信存储而更相信用安全的算法即时演算的原因 ... 不过我觉得这大概不是我们的争议点 ... 我写一个这个密码生成器的 chrome 插件似乎好过说更多的话 ... |
16
julian 2011-12-22 13:18:41 +08:00
正好想用随机密码,楼主这个作品帮了我的忙,谢谢!
|
17
bhuztez 2011-12-22 13:19:31 +08:00
@Sunyanzi 我是觉得使用自己折腾一个算法不合适,如果使用现成的算法,那么就算离开了你的工具,只要会写Hello,world!,谁都能自己调用下库生成一下。就算自己用,也可能会忘记掉当初是怎么写的,如果用现成的算法就没什么好担心的了。
|
19
yangzhi 2011-12-22 13:30:47 +08:00
@Sunyanzi "我写一个这个密码生成器的 chrome 插件似乎好过说更多的话" 这是个好主意啊,自动根据当前页面的域名来做辨别码就很方便了
|
21
RoyLaw 2011-12-22 13:36:11 +08:00
好久没见鸭子了,其实Lastpass就可以了啊,生成随机密码再保存。。
|
22
napoleonu 2011-12-22 15:19:42 +08:00
我对LZ已经五体投地了,以后就是这个了,不过要是再美观点就好了 :)
|
24
frittle 2011-12-22 16:16:24 +08:00
@Sunyanzi 嗯,那不是争议点。不过还是补充一下LastPass的操作:储存在LastPass服务器上的资料都是在用户端加密和解密的,所以就算他们家数据库被盗了,也没什么好担心的。 http://goo.gl/lSN7t
|
25
Sunyanzi OP 冷静下来想了一下 ... 我这个东西的局限性还是挺大的 ...
比如许多地方的密码不能粘贴 ... 做成手机 App 的话 ... 每次看着手机输密码又太累 ... 浏览器插件的话我可以自动根据网站域名生成辨别码 ... 网站域名一变就全完了 ... 所以说还是当个玩具好了 ... 实际应用还是没办法让它操作简单又安全 ... @napoleonu 多谢支持 ... 界面的话其实 ... 难看的一如既往 ... http://www.google.com/#q=site:mop.sunyanzi.cn 可以参见上面链接 ... mop.sunyanzi.cn 下面的东西都长成这个样子的 ... 还有些不知道为啥没被 Google 收录的比如 dice ... 长得都一个样 ... 算是难看的统一吧 ... @frittle 我看了 LastPass 的文档 ... 确实是我之前了解的不够 ... 可不管怎么说我还是难以信任任何存在【中央数据库】的密码计算机制 ... 我只相信公开的算法 ... 这大概是我的某种病态的偏执吧 ... 你说 ... 假如有一天 LastPass 莫名的被 GFW 了 ... 我们的密码怎么办 ..? 谁能保证这些服务是永远可用的呢 ..? |
26
qq286735628 2011-12-23 13:39:07 +08:00
不错
如果做成浏览器插件的形式,会方便很多 公开的算法,会不会像MD5一样,虽然是不可逆算法,但是当用的人多了,就会有人开始收集字典 |
27
Matata 2011-12-23 13:58:04 +08:00
我是进来膜拜孙大大的
|
28
Sunyanzi OP @qq286735628 这东西虽然小但是蛮健壮 ...
底层算法是基于 HMAC 的 ... 组合算法涉及一切用户填写的内容 ... 也就是说 ... 在使用同样的主密码和同样的辨识码的情况下 ... 只要密码长度不同或组成不同生成的最终密码就会截然不同 ... 想做这个综合算法的彩虹表我真心觉得很困难 ... |
30
yyfearth 2011-12-23 17:19:44 +08:00
只要算法够复杂准确,结果唯一,那么只要记住算法和主密码就可以达到存储密码的目的,就像Lastpass和1Password一样。
|
31
yyfearth 2011-12-23 17:22:20 +08:00
@Sunyanzi @qq286735628 对呀,就算算法公开,只要加盐不同,结果就会截然不同。破解的唯一方法,就是拿到你的完整加密方法,然后估计字典重新生成彩虹表,这样代价会很大。而且,只要你主密码足够复杂,完全可以无视爆破。
|
32
yyfearth 2011-12-23 17:23:00 +08:00
这个办法的唯一问题就是,由于没有存储,如果一个密码废掉后,没办法得到另一个密码~!
|
33
feiandxs 2011-12-23 17:42:29 +08:00
|
34
Sunyanzi OP |
35
Fann 2011-12-23 23:06:28 +08:00
@Sunyanzi 非常感谢 lz 分享,保存了一个本地版本(本地更快的加载速度 :D)准备试用一段时间,目前想到的成本就是每次多费事一小下。
生成器里有一个 算法版本,可能 lz 会有改进修改,是不是放到 Github 这种方便跟踪更新? |
36
yyfearth 2011-12-24 08:43:54 +08:00
@Sunyanzi 我的意思是,如果你用固定的算法,那么同一个网站只可能有一个密码,如果这个密码必须换掉,那么你没办法用同样的方法获得一个新的密码、
|
38
Sunyanzi OP @Fann 算法版本的意思是将来哪怕我又冒出什么想法更改了新算法 ...
原来的算法也不会消失掉 ... 始终会保持在可用状态 ... 目前这个密码生成的算法是我能想到的安全级最高的办法 ... 如果更改的话也是降低安全级往更人性的方面修改 ... 比如密码长度不影响生成的内容 ... 只是用于截取 ... 比如替换掉密码中 0 O / 1 l I 这样不易看清的字符 ... 比如生成符合用户规则的密码如【包含四个大写字母四个小写字母四个数字两个符号】等等 ... 每一个算法我测试通过之后会直接以一个新版本的形式放上去 ... 应该不用 Github tracking 吧 ... @reducm 一般来说不推荐更换主密码 ... 主密码如果有好多种不方便记忆 ... 对于 @yyfearth 的情况也许可以用在辨识码后面加尾缀的方法来改变 ... 如原来的辨识码是 site ... 因为某个原因不得不改密码的话 ... 其他都不动 ... 把 site 改成 site1 就会有新密码生成 ... |
39
leungxh 2011-12-24 16:34:49 +08:00
最好不要《生成密码的属性》,因为不可能把每个网站的属性都记住啊。
像花蜜那样不要选择就好,可惜这东西在手机上不太方便用。 |
41
derekwei 2011-12-24 18:29:09 +08:00
我觉得lz的想法非常好,但就是在密码版本上应该想一个比较好的方法,如果就靠用户去记忆也是意见麻烦的事情
|
42
skywinger 2011-12-24 18:53:51 +08:00
@Sunyanzi 我觉得密码还是用可逆的算法来比较好,用把公钥来加密就好了,用3DES或是RSA算法就可以了,hash算法不可逆,充其量只能算电子签名,不能算加解密算法。
|
43
Sunyanzi OP @leungxh 请无视那些内容 ... 我每个属性都有默认值 ... 当它们都不存在 ...
只要永远不改就会永远生成 16 位的大小写字母加数字密码 ... @derekwei 下个版本应该会引入把辨别码记入本地 cookies 的功能 ... 在不使用 LocalSharedObject 的情况下这是唯一的保存内容的方法了吧 ... @skywinger 这又不是加密算法 ... 这是密码转换算法 ... 哪怕明文内容再长 ... 生成的内容也必须定长 ... 以及过程必须是不可逆的 ... 加密可以参考我的马赛克生成器 ... http://mop.sunyanzi.cn/mosaic/ ... |
44
delectate 2011-12-25 11:08:05 +08:00
楼主的好东西真多:
http://www.google.com.hk/#hl=zh-CN&newwindow=1&safe=strict&site=&q=site:http:%2F%2Fmop.sunyanzi.cn%2F&oq=site:http:%2F%2Fmop.sunyanzi.cn%2F&aq=f&aqi=&aql=&gs_sm=e&gs_upl=1914l3536l0l3745l3l3l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=ccab00aec9275914&biw=1200&bih=657 做成浏览器插件,自动根据域名和主密码+salt生成密码。支付宝插件就不支持粘贴。手动输入又有可能被偷窥。今后要是都是身体特征识别就好了,没有密码。指纹什么的。 |
47
KiseXu 2011-12-26 09:04:13 +08:00
你好,我是花密 http://kisexu.com/blog/huami 的作者,关于你说的只能生成 /[0-9][A-F]{16}/i 这样的密码,其实我是有过考虑的,我希望生成的密码有通用性,某些站点的密码不能用符号……
|