浅谈用户名密码登录方式的弊端

纵观互联网，绝大多数网站都采用用户名和密码的方式认证用户的身份。安全问题百出。

首先，密码存储问题，服务器端肯定不能存储用户密码的明文(前段日子的密码门事件让我们认识到了事情的严重性)。那么服务器端存储什么呢？密码的Hash值？还是(密码+随机数)的hash值(随机salt二次加密)？

下面细细道来。

服务器端存储密码hash值的话不大靠谱，如果黑客获取了服务器数据库的话，随便找一个明文，做一下hash，和数据库里面的hash值对比一下，就可以找到一大批具有此hash值的用户名。也就意味着，黑客轻易获得了一大批用户名和密码（虽然密码都是同一个）。

salt二次加密技术还是比较靠谱的一个，起码从服务器端入手的黑客需要耗费相当大的力气去找碰撞。但是salt方案就安全吗？我的答案是否定的，正所谓无孔不入，此路不同另寻他路。

既然要使用salt二次加密方法，那么用户在登录的时候肯定是在网络上传输了自己密码，明文传输可靠吗？稍微会用sniffer就能抓到一大堆用户名密码。

传输过程中绝对不能明文传输密码。那怎么传输密码呢？也传输hash值吗？

传输hash值？有意义吗？照样可以用sniffer把hash以后的值截下来，然后自己手工构造数据报文，把hash值贴上去。同样也能通过服务器端的认证。

额。。。传输hash值不行，那怎么办呢？传输一个密码的变形？使用挑战/应答模式？

A----"我要登陆"----->B

A<----"随机数R"-----B

A------"用密钥对R加密"----->B（收到以后用自己保存的密钥对密文解密，验证用户身份）

这个方案？还是服务器端存储了实际的密钥啊。。。。又被否定了。

难道要使用DH密钥协商，临时协商一个会话密钥，使用这个会话密钥对(实际的用户密钥的hash值)进行加密？这个貌似可以......

老天。。。总算找到了一个可以使用的方案。。。。但是又有多少网站支持SSL加密？

在这个团购网站盛行的时代，相信如果你去注册这些网站的时候会用同一个用户名和同一个密码吧。万一某一个网站安全方面做得不够好，导致密码泄漏，掰掰手指头算算自己损失了多少吧。。。