假设拖库很难避免,但加密就安全么?

　　但如果攻击者不是只获得了库，而且也获得了相关的加密参数和密钥，我们就要看到攻击者依然可以自己通过相关参数和密钥调用算法，使用常见密码对每个用户生成一遍密文，然后是否有匹配。当然我们可以看到由于“每人一粒盐”的策略，攻击者所需要的计算代价已经变化了，如果过去只需要生成一次的话，那么假如使用100个常见的口令来做，那么只要口令没有碰撞到，对每个用户都要做100次加密操作。但这也是不容小觑的威胁。因为有太多用户喜欢使用那些常见口令。

　　因此，设定一个密码禁用表，让用户避免使用常见口令，可以进一步让破解者付出更大的代价，从而最终导致计算资源不收敛而放弃，也可以是一个可以考虑的策略。但也需要提醒WEB开发者的是，这样会增大你的用户忘记口令的风险。

　　另外，用户是否有把密码设置为123456的自由呢，我想只要不是国防、航天、涉密系统和有安全要求的企业环境，如果只是潜潜水、骂骂街，网站或许提醒用户就好，但也许并不需要做成强制策略。

　　具体的实现

　　了这么多，怎么来具体实现一站一密、一人一密的策略呢，2011年12月23号，我们想到与其空洞的说教算法原理和策略，不如提供一些非常直接的示例程序和文档。

　　因此同事们写了一份名为AntiyPasswordMixer（安天密码混合器）的开源代码，当然这没有什么技术含量，也不是“自有知识产权的国产算法”，有的只是对实现较好的流行开源算法包的示范性使用而已，目前的Python版本，也只有三百行代码，在其中封装了RSA和HASH+SALT使用，并给出了具体的在初始化、注册和认证时如何使用的范例文档。

　　大家可以在这里找到这个东西：

　　当然，就像我们惋惜很多应用开发者缺乏对安全的重视一样，其实我们并不懂应用开发，所以这些代码和文档对于应用开发者看来可能非常丑陋。尽管可能被鄙视，我们还是要打开门，证明安全团队并不保守。

　　而同时，我们必须与应用走得更近，因为我们也在使用着这些自认为违反了某种安全原则的应用，却因为不是其开发者而无法改造它们。

　　过去的10余年，中国的Web应用甩开安全而飞速狂奔，开发者们凭借自身的勤奋和冲击力奠定了现有的格局，但也因快速地奔跑遗落了一些东西，比如安全。也许现在是拾起这些弃物的时间了。

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!