我的密码策略：密码生成器

“泄密门”从2011一直泄到了2012，今天国信办终于给出了查处结果。事件虽然画上了一个句号，但“密码保卫战”却从此吹响了号角。面对各式各样的网络服务，作为一个普通用户往往疲于应付。这样一来的结果通常是，一个密码走天下。如果没有“泄密门”，我想基本不会有人产生警觉；更进一步，即使产生了警觉，对于密码泄露这样的事，作为用户，到底该怎么办呢？（当然，也不排除到现在还有很多人没有意识到问题。）

危害是什么？

这里有一份所谓黑客自爆入侵以及黑色产业链的报道，你或许可以在网上搜到更多。但在我看，这个泄密的真正问题在于，密码这样的隐私或者说你的加密思维被坏人知道了，产生了隐患。之所以是隐患，是因为这样的绝密信息，不一定会被人马上利用，也不一定会被人利用到当前的账号。

举个简单的例子：假设，a网站和b网站你的密码分别是123456a和123456b。a网站没什么价值，而且服务器端安全措施做的很一般。那么当黑客攻陷了a网站的服务器的时候，就对你的b账户就产生了威胁。你会说密码设置不同呀？但实际上之前的泄露已经为黑客增加了攻击你的思路以及筹码。一个有经验的黑客，如果真的盯上了b网站上的账号，估计在半个小时内，就能通过密码工具猜出你的账户密码来。

在前面这个例子里，用户还比较有防范意识，针对不同的网站，给出了不同的密码。但事实上很多网民，在使用网络服务的时候，都傻傻的只用一个账户和密码，或者近似的密码。因为密码多了，实在是记不住啊。对于这一点，我本人也深有体会。

我的密码策略

这段时间看了很多这方面的文章，也正在读关于密码攻防的书。虽然只看了两章，有了一些想法，想先罗列下来：

• 对于服务端，是否加密保存，用户无权过问，它会给你说这是“商业机密”；服务端是否安全，用户问了也没用，因为没人会告诉你不安全。用户用的是服务，理应完全信任服务器。不然，在这个信息流通环节，任何一环不可靠了，信息就无法流通了，当然也就无法产生价值了。退一步讲，你用这个服务，就要给个“密码”。所以，你看着办。
• 但从国信办给出的调查报告来看，一个让人不得不担忧的结论浮出水面：“广东YY语音聊天网站泄露的数据，系该公司员工利用职务之便从公司内部备份数据库窃取的。”试想，如果服务端的工作人员，可以轻易的接触这些敏感信息的话，并且这些敏感信息在坏人们手中流通的话，还并且保护你的敏感信息的密码因为便于记忆而透露出你的加密思维的话，那么，你危险了。
• 在传统加密体系中，最安全的方法便是“一次性密码簿”。明文根据一次性的密码簿产生出密文。这样做的好处是，明文下次被加密的时候，会以不同的密文呈现。而对于攻击者而言，除非拿到密码簿，否则无法猜解明文的信息。而对于明文的撰写者来说，明文从未变过。
• OK，简单的说，我的密码策略是：借用密码生成器实现一站一密码。这样做的好处无非以下几点：密码强度足，加大了攻击者的攻击难度；即使被服务器端的工作人员出卖了，也不怕其他服务器的信息沦陷；没有记忆负担。

实现思路：

思路也很简单，将常记密码做为计算对象，并将使用服务的标签作为“盐”（SALT）对计算结果进行扰动，使用现行的牛X单向函数算一个值。这个值的特性在于，1）确定性，被计算的对象经过反复计算的结果是统一的；2）不可逆，其他用户拿到单向函数的算法以及计算结果，无法推测被计算对象（也就是常记密码）；3）复杂性，满足密码强度的需求。这样，用户在登陆网站的时候，只需要拿出密码生成器对常用、好记的密码进行一次计算，即可产生出强度足够高的密码了。

通俗的说，用常记的密码作为爸爸，用服务的名称（或别的什么）作为妈妈，生一堆密码儿子。任何居心不良的人要从儿子找到老子、娘，几乎是不可能的。而为了突破可能要付出的代价，基本上超越了小用户讨论的意义。嗯，大致的如下图所示：

实现：

第一次用c++ 写桌面程序。单向函数，用的MD5。看了一下文档，原封不动的实现了。但昨晚分析生成结果的时候发现密文的局限性在于只有16进制的显示。换句话说，生成的密码F以后的字符就没了，更不谈特殊字符。于是，后来的更新版本对密码做了1次散列，再于是，便可以看到下面这样的密码了。

FAQ：

1，公布了实现细节，密码生成器还能用吗？答案是肯定的。

我的观点如下：1，黑客，或者密码分析者通常得逞不是靠暴力猜解。牛X的黑客，通常会从掌握的其他信息入手，俗称“社会工程学”。换句话说，被牛B的黑客盯上了，密码已经不是最重要的了。整个信息领域的安全系统才是关键；但，我们能做的是提高每一个敏感信息的破解难度；2，充分相信数学家对MD5算法的不可逆性的验证。比起某些国产知识产权的算法来讲，MD5有着更高的性价比；3，对于彩虹表的破解，我想说，我们这个工具生成的密码已经不是传统的一次MD5或者说多次MD5的计算结果，刚才也说过，计算结果被重新散列了。要想用彩虹表破解，黑客需要针对我们的程序重新生成新的彩虹表。这个代价足够大，大到让那些黑客放弃对我们的攻击。

因此，对于民用密码工具来说，我想这个生成器是够用了。

2，对密码生成结果做一份备份保存。

这个问题，我权衡过：如果要把生成结果，保存下来，对于这样的日志信息放在哪里比较安全？作为谷粉，我比较信任google，是不是放到google docs上？一个密码生成工具还具备联网通讯的能力貌似说不过去啊，谁知道你是存到谁的docs上了！放在本地？如果加密保存，对于用户来说，更没意义。因为加密后的信息无法唤醒任何记忆。而明文保存，无异于将敏感信息集中保存在了一个毫无防备的硬盘里，等着别人来拿。嗯，所以三思之后，这个功能就被我砍了。退一步说，既然使用的是常记密码，而标签（SALT）是自己设的服务名称，在唤醒密码记忆的时候基本上是没有压力的。

3，生成的密码，太复杂，难得记下来。

生成的密码，是不用记的。你看不懂密码，我也看不懂，正常人都看不懂。但你需要记得，用什么关键词生成的密码。下次填写密码的时候，需要重新运行一次程序来计算。现在很多浏览器都有记录当前密码的功能，登陆成功后，可以让他们帮忙记住，免得下次输入。呃，算是一种，比较小众的工具吧。

一句话：只对Google，Microsoft这样的巨头放心，其他的还是多留一个心眼吧。

文件下载

dbank下载  |  skydrive下载

File Size: 574759 Byte(s) (561.29 KB)
Modified Date: 2012-01-11 00:42
MD5: cf94f92c2077479a9329b6a23fc6ed67
SHA1: 392a9dbc91ba65486b70205be6f1e533ba26ca32
SHA256: 1fd03ef08c05b015dbc772ff4d90300f799945fd65cb755fda4a9b93942d475a
CRC32: f6bd99f9

UPDATE:

很快的，用工具修改了一些常用网站的密码。悲剧的是，今天早上躺在床上用手机登陆微博的时候，却发现要重新填密码。我晕了个晕，看来一会要在android上做一版本出来。

关于移动终端上的密码更新问题，想来想去还是觉得移动操作系统品种太多，单靠个人的精力是无法满足开发需求的。一个比较好的思路是，借助同步工具，可以将相关密码同步到移动终端上来。比如鼎鼎大名的evernote，国产的有道笔记等，相当的方便。因此，在这里，我就不放出android 版本的APP了。思路仅供参考。

看了上面的几次update，你不难发现，我是一个纠结的人。虽然，自认为上述代替方案够用，但今天还是手痒，写了一个android 的版本。看到后台下载统计的次数，我想，这里就不放出移动版本了。有需要的人给我邮件吧。