2023年7月27日发(作者：)

WEB⽹站设计⽤户登录的安全机制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(密码+盐)的明⽂，则因为盐是随机的，所以⿊客在暴⼒破解或者字典破解的时候，则⽆法通过彩虹表或者字典表找到对应的密码明⽂或者耗费超长时间才能获取明⽂（因为盐是随机的，所以可能性很⼩）。