密码为什么明文存放

 

很早就写过一篇blog,说到过,你的密码应当一次一密,至少某些密码泄露时不至于波及太广。结果这次CSDN不幸中枪。我不去讨论多少人急急忙忙修改密码,多少人数据泄露,单说说为什么很多时候密码是明文存放的。

就我有记忆以来,我写应用就从来没有明文存放过密码。最起先是md5方式存放。md5可以让你找到hash值,有的时候也会被用于穷举。但是无论如何,md5密码本身比明文安全很多。后来改成了challenge-response验证模式,也是用md5做的hash后进行c-r的。再后来,md5的碰撞冲突的论文出来,后面用的多数都是sha256了。从头到脚,我就没做过密码明文存放,并且,我认为这是正常程序员最起码的修养。(当然,明文存放的代码不是没有,不过那是调试模式) 但是现在我所知,很多系统的身份验证都是密码明文存放的,为什么?其实我不大理解。不过有时候问起,有些人和我说了几个我觉得不是搪塞的理由,现在抄录如下,告大家知。

1.明文密码没法应付检查。大家知道互联网审查,有时往往会一个电话过来,要XX用户的密码。如果你没法给出,上头就认为你不配合,事情各种难搞。作为审查机构的老板,当然没必要知道明文密码的危害。他们只知道,我要密码,为什么不行。所以,悲崔的程序员们就往往会得到一条死命令,保存明文密码。

2.压根不知道明文密码有什么问题。中国的互联网有太多的没基础的新人,从石头的缝隙中顽强的生长出来。这不是坏事,坏事的是这些人往往会在一些基础问题上出现奇怪的毛病。例如有些程序员,写程序很快,但是居然从来不知道密码明文存放会导致什么问题。更神奇的是,这些人中,有一家银行…

3.自信暴棚的混帐。有些人的自信总比别人强,而且强在莫名其妙的地方。例如:我的服务器肯定是没问题的,所以我的密码一定要明文存放。如果不,就是质疑我的技术。

实话说,这种人真是少数中的少数。

4.遗留系统。很多系统设计的时候因为某个其他理由,使用了明文密码。等后来这个理由不存在了,密码系统升级成了一个困难。因为密码系统太重要了,所以在没有太大利益的情况下,总是倾向于不修改系统。但是有什么足够利益来推动系统修改呢?用户安全问题在发现前不是一个问题——好比这次的CSDN,不是被暴出来的话就根本不会被当作一个问题。系统的管理者,每个人都没有足够的动力去修改系统。

5.世界的阴暗角落。有的时候,程序员/老板明文存放的理由,是为了方便盗窃用户其他网站资料。例如我所知的某钓鱼案例,你注册网站,就提供很多免费服务,网站看起来也很靠谱——除了后来突然爆出这家网站其实暗地中用你的生日/密码猜解信用卡/银行卡密码,大家才突然发现,这家网站其实根本没有在美国注册,而是一个听都没听说过的国家。

而且很多网站提供从其他网站导入之类的功能,更加的危险。以前经常爆出twitter密码被窃取,主要就是因为OAuth开放以前,twitter上的第三方应用需要提供原生密码,导致很多小应用的目的其实就是收集密码…

6.为了给用户提供方便。这个理由和上一个很类似,不过不是为了某些险恶的目的。而是客户经常要求——为什么我不能做XX事,为什么我不能blahblah。好吧,为了让你能,我们就必须保存明文密码。

明文密码的保存原因很多,不过结论都是一样的。在任何网站/服务上,你绝对不能使用同一个密码,零级密码除外。尤其请注意,不要在两家银行使用同样的银行卡密码/网银密码,原因不说。

从未来进化的角度说,密码的未来进化趋势是核心授权体系。就是你要向某个网站验证身份,只需要向身份验证商验证,剩下自动完成。现在的openid就是一种解决方案。密码都没了,还谈什么泄露呢?同时,实体交互和授权的精细划分也是一个趋势。某个网站访问别的网站的数据的时候,会形成一个访问令牌。这个令牌对需要访问的内容详细写明,并且需要用户授权。OAuth就是这个趋势的代表。另外一个趋势是利用某个足够安全的设备作为以上两者的终端载体。目前这个设备用的是手机,可是——手机不是一个足够安全的设备。也许这会是下一个XX门的隐患吧。

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据