密码安全策略

droplet's picture

最近一段时间,关于密码的安全问题暴露了很多,先是各大安全公司公布的常见密码,后来又是CSDN的密码泄露事件。按道理说,密码是第一道安全防线,应该引起足够的重视,但在实践过程中,问题依然不少。

首先是弱密码的问题。密码做为用户认证的一种方法(something you know),是最简单的,但也是最不安全的一种。密码的选择应人而异,选择密码首先要容易记,还有就是输入方便。其中最重要的就是容易记。这个和其他认证方式,比如something you have(比如token),something you are(比如指纹,虹膜等)相比,在于需要记。如果是随机选择的密码,显然是不容易记住,容易记住的,都是和个人习惯相关的一些密码。比如宠物名称,电话号码,键盘上相邻的字符等等。而且大多数人总是倾向于不同的网站用相同的密码,这样减小了记忆的负担(特别是一些不经常用到网站,时间长了,就都忘记了),但是一旦一个网站泄露了,其他网站也可能就没什么秘密可言了。

解决弱密码的问题,首先应该保证密码有足够的长度,通常会要求8个字符以上的密码;其次应该让可选的字符集足够大,包括数字,字母和一些特殊字符,如果能支持中文密码就更好了(输入比较困难,如果有,会有哪些常用密码?);还需要一个密码强度的检验功能,在用户密码强度不够的情况下能够提示(通常来说,包含数字,字母,大小写,以及特殊字符的密码应该会好一点,但是如果是一些常用的模式,强度也是不够。密码的强度取决于破解所需要的时间,但是abcd和abcd1234哪个强度更强一点哪?从破解角度来看,基本上是一样的)。有没有好用一点的密码管理工具哪?可以试一下。

解决了密码选择的问题,接下来就是密码传输的密码。在非安全通道上传输密码,至少应该把密码加密了。很多早期协议,用到都是明文传输密码,所以很容易被窃听。但是加密这个密码,用什么做密钥哪?也许做一个哈希是更好的选择,至少不用担心密钥的问题。

最后就是密码存储的问题。明文存储是不行的,所以要保存哈希值。通常是MD5或者SHA。为了避免字典攻击,还需要在这个哈希值外在加上一个Salt,也就是说,在生成密码是,在附加一个随机数,也就是说在用户密码上再附加一个系统的随机数。用户密码加这个随机数,然后算一个哈希值,增加攻击的难度。

有些人提出用openauth来解决密码保存的问题。openauth出来很多年了,也没见有多大的起色。一般都希望把用户抓在自己手里,谁愿意把用户数据托管在别人哪里。不过用openauth的好处是可以共享别人已积累的用户,现在最常见的用法,也仅仅是方便用户第一次使用而已,而且一旦auth服务出错,其他的服务都没法用了,还是谨慎一点好。

信息的重要性决定了密码的强度。对于一些更重要的信息,比如网上银行,网上购物等等,单是用密码已经无法保证安全,需要加入其他的手段,比如证书,token,one time password等等。密码泄露了,并不是每个人都着急,原因就在于信息对每个人的价值是不同的。

补充几点:

1)显示名和登录名分离,不要公开登录名。用户设置也应该设置不同的名称。

2)需要限制尝试登录的次数,帐号锁定后,需要验证才能解锁,当然,这个和需要保护信息的价值有关系。高价值的西信息,用户不会觉得麻烦,如果是不重要的信息,这样做,用户就会觉得麻烦。

3)动态密码有很大的应用空间,比如手机动态密码,或者软件动态密码(RSA token据说要几百美元,太贵了,部署成本有点高)

4)任何安全策略的制定,都是基于对资产的评估,比如信息资产的价值。太多或太少都是不合适的。

0
Your rating: None