为什么低级的错误密码策略频繁出现

ZDNet安全频道原创翻译 转载请注明作者以及出处

作者：乍得·佩林

当你认为自己已经看到了有史以来最坏的安全策略的时间，其实你错了，偶然发现的东西可能会让你看到更令人惊讶的情况。
--------------------------------------------------------------------------------------------

教育服务公司Nelnet，这个公司的具体业务可能有人并不了解，它的全称是“国家助学贷款网”。服务对象是需要管理助学贷款的学生，这也就意味着他们需要对人们的学习年限以及贷款情况等资料进行管理。网站需要通过信用卡号码自动付款，为了显示国家助学贷款网如何在线处理这类敏感的资料，请看一个例子。

这就是我在国家助学贷款网上看到的一个令人吃惊的页面：

如果你看不到截图的话，下面是这个密码要求的页面的内容：

· 区分大小写

· 不能包含特殊字符(?&%$#@+=!'~,等）

· 不能包含你的用户名

· 不能包含两个分开的数字（象Abc12ef34这样的密码将是无效的）

· 不能包含“Nelnet”或“Password”

就密码的限制条件，我与TechRepublic网络日志的作者先令·康登（他负责撰写资讯科技顾问部分的网络日志）进行了研究。在随后的讨论中，他说：“我已经看到了一些网站，不容许密码超过六个字符，而且禁止使用数字或特殊字符”，原因是他认为 ，有些网络开发人员“过于执作于防止SQL注入攻击，即使他并不了解攻击的实际原理”。从这里我们可以得到一个教训，在仅仅了解一些特定的安全威胁，而实际上并不是真正的认识它的时间，将用户的密码人为地限制在很薄弱的状况下，这种可能发生的错误会降低整个系统的安全。

在这场讨论中，我发现，为什么一些网站会选择限制密码的选择，甚至只允许使用字母字符-可能区分大小写。一个知识非常贫穷的开发人员可能只是不了解在一个特定的开发环境下如何编程可以处理区分大小写的包含多个字母数字字符的代码。我不是说这个事情是好的，只是说我理解它为什么是有可能发生的。

我不明白的是国家助学贷款网的密码限制的第四条，“不能包含两个分开的数字”这样的情况。什么样的离奇杂牌代码会认为在同一个密码中包含两个分开的数字在处理的时间会非常困难或者存在危险？难道还存在对数字进行检测的代码？这是一个非常天真（容易失败）的限制，企图“强迫”人们做一些比1337speak（也写作“l33t speak”，是一种基于因特网要用键盘输入独特的语言，在现实生活中基本上不使用。）更聪明的事情？我真得非常难于理解这件事情是怎么发生的。我忽略了什么明显的因素了么？

就国家助学贷款网的这个必须的非常奇怪的密码验证后端代码产生的疑问，我问了一下先令。他的回答是，“我敢打赌，该验证代码的作者一定可以作为“每天都见他娘的鬼”（Daily WTF）网站（这个网站列出了他们所搜集到的千奇百怪的“程序错误报告信息”。）的候选人之一。”我也同意这一点。

是的，等等就会变好的。相比其以前，国家助学贷款网荒谬的状况是有所改善。不久前，用户在国家助学贷款网上还没有选择用户名的权力。他们不得不利用社会安全号码作为用户名。与用户名相比，社会安全号码被银行、学校和世界范围内所有的其他大型机构每隔几分钟就查询一次，它应该被当作敏感资料。毕竟，它很容易在身份欺诈行为中使用。

想象这样一种情况，所有要求社会安全号码进行身份验证的地方，如果被获得你的号码的人所冒充，会发生什么样的事情。人们可以从一个地方很容易地获得你的社会安全号码，然后将它用在其它地方，获取到一些原来不能得到的信息。

生产力不等于速度。它是和速度有关。你可以高速前进，不过如果方向是错误的话，对任何人都没有帮助。

这是菲利普·J·哈克的话，它们听上去非常中肯。我猜想，国家助学贷款网不在使用社会安全号码作为登陆方式，是在向正确的方向前进。只是它们的速度不够快。但这总比在错误的方向上高速前进好。
 
我只希望国家助学贷款网不要利用JavaScript客户端进行所有的密码验证。