WEB网站设计用户登录的安全机制

╰+哭是因爲堅強的太久メ 2022-06-07 08:23 200阅读 0赞

1   服务器端不要保存密码明文，因为攻击者甚至不需要很高深的技术，利用SQL注入就可以获取所有的明文密码，后果严重。

**如 sql注入问题 :**

**   select \* from user\_table where userid='x' and password='1111';--正常的sql**

**   注入sql**

**   select \* from user\_table where userid='x' or (1=1) --'   and password='1111'  ; 输入参数userid= x ' or (1=1)--   x为任意值。**

**   最终sql变成**

**   select \* from user\_table where userid='x' or (1=1),后边内容全部作被注释掉了，因此可以获取所有用户的信息。**

2   服务器端也不能保存密码的哈希值，按理说哈希值是单向的，不可能被逆向，只能要么字典要么暴力破解，但是时间上很难接受(比如需要几天甚至几年，取决于密码的复杂程度和计算机运算能力)，但是这世界上竟然有查表(彩虹表)攻击，也就是说攻击者可以先行建立一张"所有"明文密码到哈希值的对应表，这样拿到一个哈希值几秒钟就能获取其对应的明文密码。假设网站有10万注册用户，并且其中10%的用户密码很简单，那攻击者通过简单的查表也许几个小时就能获得这1万用户的明文密码。

**常用的非对称加密算法有hash，md5加密等。 hash后存储是相对安全，但是不是绝对安全，见第3条。**

3  服务器端的密码应该保存"加盐"(salting password)后的哈希值，所谓加盐是指在密码前加一串随机字符串，注意不能用固定的字符串加盐，因为假如盐固定，那攻击者还是能事先建立起彩虹表，那就回到了上面的规则2，所以应该每个用户用不同的随机盐。

4  客户端保存密码(因为有自动登录的要求)的规则同服务器保存规则。

**  拿到用户的cookie可以自动登录了，因为cookie可以包含用户登录的所有信息。**

5  客户端不能传送明文密码到服务器作登录校验，在用户和服务器之间有太多恶意设备的可能(嗅探，代理,AP，路由器...)，有的客户端甚至用GET传递明文密码，那普通的代理log就把用户密码给泄露了。

6 客户端也不能传送密码哈希值到服务器，一个原因是规则2的彩虹表，另一个原因是对于你个人，黑客甚至不需要破解到明文密码，复用这个哈希值就可以登录某人账户了。

** 采用https协议进行密码传输，可以防止传输时密码被截获。**

7  客户端也不能把加盐的哈希值传到服务器，虽然这么做可以避免彩虹表攻击，但是由于该哈希值是固定的，黑客还是能复用该值做登录用。

8  作为登录校验的值必须是不固定的，由于密码和盐是固定的，所以必须加入个随机值一起做哈希。客户端可以预先从服务器处获取个随机值(比如时间戳)，然后和加了盐的密码哈希再哈希一次。这样就算是中间人(MITM)攻击也无效。

**hash（时间戳+hash（密码+盐）） 时间戳不传输，但是需要在服务器端存储相同的时间戳。**

9  假如客户端是js网页，规则6就尤其重要，因为黑客可以通过修改js网页(恶意http代理)，使密码作哈希值的代码失效，后者直接就能拿到明文密码。

10 由于登录时服务器和用户共享个第三方无法知道的秘密(密码)，因此简单的设计就能保证很高的安全性。难点在于注册阶段，因为要保证用户设置的密码(包括哈希值，包括加盐哈希值)不在网络上传输到服务器，这只能通过**https或者短信**注册来保证安全了，当然这2个方法本质上还是"服务器和用户共享个第三方无法知道的秘密"，前者通过非对称加密的公钥私钥作秘密，后者通过网络黑客无法截获(手机没中病毒)的动态密码作秘密。

11 总结

即使用户能够拿到has(盐+密码)或者has(密码+盐)的明文，则因为盐是随机的，所以黑客在暴力破解或者字典破解的时候，则无法通过彩虹表或者字典表找到对应的密码明文或者耗费超长时间才能获取明文（因为盐是随机的，所以可能性很小）。

参考博文：http://blog.csdn.net/azhegps/article/details/70851649