最近一段时间，关于密码的安全问题暴露了很多，先是各大安全公司公布的常见密码，后来又是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等等。密码泄露了，并不是每个人都着急，原因就在于信息对每个人的价值是不同的。