基于哈希算法的web账户口令存储方法

  web账户的口令不能直接明文存储,这样太不安全了,需要加密存储。

  1. 存储策略—— 基于安全哈希算法加密存储用户的口令

  估计基于安全哈希算法的存储方式应该已经广泛使用了,不过奇怪的是网上难以找到相关应用的详细资料。哈希算法可用于保障信息的完整性、抗抵赖性, 属于单向算法,即便哈希的结果被截获,对方也是无法还原出明文的。如果在哈希的过程中加入盐值,那就更好了,可以起到混淆的作用。盐值这个概念找不到定义,大概是指用户间相互不同的信息,常见的用户名、用户邮箱、账号注册时间等。

  类似地,选择基于哈希的消息认证码(HMAC)也可用于身份认证,安全性更强,如果各位对单纯的hash不放心,可以使用HMAC。

  也有资料提到通过非对称加密算法加密后存储,比如RSA,个人觉得这种方法的安全性不如哈希算法,使用起来也麻烦,需考虑系统后台的密钥管理,而一旦密钥泄露,所以信息也就都白加密了。

  2. 算法的选择

  哈希算法有很多,常见的有MD5和SHA系列。现在有个叫彩虹表的东西,穷举某个哈希值所对应的明文,导致了MD5和SHA-1已经不再安全。而SHA-256或SHA-512目前还是比较安全的,而且计算消耗的资源不会比MD5或SHA-1差太多。从代码实现的角度考虑,各算法的参数都一样,返回值类型也一样,只是函数名和返回值长度变了,所以如果已使用了MD5或SHA-1,可很方便地切换到更安全的算法上。

   3. 添加盐值

  以盐值为用户名,算法为SHA-256为例,用户最终存储在后台的口令就可以为SHA256(" 用户名+口令 " )。而登陆的时候,有两种验证策略:

  • 可在客户端计算出SHA256("输入的用户名+输入的口令"),将计算的结果明文传输给服务端,由服务端比较该值与后台数据库中存储的是否相同。
  • 将输入的用户名,口令加密传输到服务端,在服务端计算 SHA256("输入的用户名+输入的口令"),再与数据库存储的内容做比较。加密传输现在比较流行的方法是HTTPS,这里就不多说了。

  可以看到,服务端是不知道用户的口令明文是什么,所以即便数据库攻破,也不会泄露用户的口令。

  再说说添加盐值的好处。大家都知道,最常见的口令是123456,假设有100个用户都这么设置了,那么如果不加盐值,这100个用户后台加密存储的口令就一摸一样了,这就是一个安全隐患。加了盐值还可以增加彩虹表碰撞的难度,就算用户使用了最简单的口令,加了盐值后也还是难以破解的。

  盐值最好选择用户注册后,就不会再改变的信息,或是由这些信息计算后的另一个值。比如,如果盐值设置成了用户邮箱,那就要确保这个邮箱不能修改,否则一旦邮箱改了,HASH("新邮箱+口令")≠ HASH("旧邮箱+口令") ,从而用户改了邮箱就不能再登录了。

posted @ 2012-04-22 16:45 苏堤白堤杨公堤 阅读(...) 评论(...) 编辑 收藏