这几天CSDN数据库明文密码泄密闹得满城风雨，人人自危。大家开始关注网络安全和隐私问题。由这次的问题，对加密验证过程我也思考过，有没有一套相对安全的存储和验证方法？这里我根据各种验证方法，确实总结了一套可行且相对安全的存储和验证方法，且看我细细道来，最后提出MySQL当前验证方法的改进。- by 谭俊青
一个系统对用户请求的合法性验证都是通过sessionid来判断的，这个层面的攻击和破解这里不涉及，我们只关心在session建立前的验证过程。密码存储的方式和验证方法大致可以归结为以下几种：
密码明文存储。比如CSDN的做法，用户登陆系统的时候直接提交明文密码，跟数据库中保存的密码进行比较，如果一直，验证通过，建立session。这时最简单，也是最傻的一种做法，所以导致了这次的泄密。对于密码一致的用户已经体会到了它的危害严重性。
密码加密存储。对用户密码进行加密存储，登陆验证的过程跟上面的验证过程类似，只是对密码进行了加密，或者对存储的密文进行了解密，然后验证。这种方法稍微提高了一定的安全性，但是还远远不够，没有从根本上解决问题，因为如果黑客拿到了密文，然后破解加密算法，可以解密所有的密文，获得所有用户的明文密码，还会导致像今天CSDN这样的局面。
密码单向hash存储。这个应该说在根本上解决了问题所在。比如存储md5(password),sha1(password)，验证时只需要比较用户输入的密码的hash值跟存储的是否一致即可验证。当然这里问题又来了因为有人会提出md5破解的问题，破解碰撞的概率现在还是相当低的，比中5亿彩票大奖的概率要低得多。但是现在有很多现有的密码字典，并且已经生成了hash值，值需要比较hash值，即可获得等价的登陆密码。因此我们对这个方法进行改进，得出下面的方法。
密码还是hash存储，不过是采用hash(hash(passwordd)+salt)的方式。这里salt可以在注册是随机生成，也可以取巧用用户名，这样可以在验证的过程增加随机串，而不用将salt输出止客户端。
对第4种方法进行变种，可以得到很多验证方法，都相对安全可靠得多，但是都存在一个问题，这个问题在mysql4.1之前的版本也存在着，就是如果有人得到存储的hash值，即可以模拟登陆，并验证通过。
现在我们回到MySQL密码的存储和验证过程。在4.1之前，mysql的验证方法相对简单，方法如下：
首先server给client发送一个随机串
client将用户输入的password的hash值对随机串进行加密，并将加密串发送给server
server用存储在user表中的password hash串对之前发送给client的随机串进行加密，生成加密串
server对接收道的加密串和生成的加密串进行比较，如果一致，验证通过。
这样的验证方法看似比较安全可靠，即使你监听网络也不会获得password或者其hash值。但是如果有人通过其他途径，获得了password的hash值，那么就可以模拟登陆系统，因此我们需要对验证过程进行改进。下面介绍mysql4.1之后的密码存储和登陆验证过程：
server存储mysql.user.Password = sha1(sha1(password))
server 发送随机串random_string至client
client 计算
stage1_hash = sha1(password) -password为用户输入的明文密码
token = sha1( random_string + sha1(stage1_hash)) xor stage1_hash
client 将 token 发送给server
server 计算
stage1_hash_2 = token xor sha1( random_string + mysql.user.Password)
sever 比较 sha1(stage1_hash_2) 跟 mysql.user.Password 即可验证
这个验证过程看似复杂，其实整个过程就是为了保证 sha1(password)不被监听到，用随机串进行了干扰。至此我们的密码存储方式和验证方法的安全性都得到了极大的提升。 当然我们发现mysql 4.1之后的密码存储还是有点小问题，没有加salt，因此存在一定的风险，可以建议官方版本改进，比如将 salt 用用户名代替，整个验证过程几乎不用大的改动。
