用户登录安全是如何保证的？如何保证用户账号、密码安全？

news2024/11/20 3:29:08

1.HTTP协议直接传输密码（无加密）

前端直接发送HTTP请求（无加密），攻击者可直接捕获网络包，看到下面的明文信息

因此，使用HTTP协议传输会直接暴露用户敏感信息。

2.HTTPS协议直接传输密码（加密传输）

后来人们提出了HTTPS协议，HTTPS协议利用TLS/SSL协议进行加密。

那么，使用HTTPS协议直接传输密码（加密传输——对称加密/非对称加密）就一定是安全的吗？

对称加密存在的缺点：

前后端加密解密需要同时修改代码；
前端加密无非是写在JS里，但是JS有风险被直接破解从而识别加密方法。

非对称加密存在两种风险：

HTTPS是应用层协议，下层采用TLS/SSL协议保证信息安全，但是在应用层之上——客户端和服务端，密文同样是可以被截获的。
HTTPS报文在传输过程中，如果客户端被恶意引导安装“中间人的Web信任证书”，那么HTTPS中的“中间人攻击”一样会将明文密码泄露。

结论是，无论HTTP还是HTTPS，密码必须密文传输

想想HTTPS也不能一定保障用户密码信息，那么就应该考虑在应用层之上再继续对密码进行保护，也就是编写代码来进行控制，而不依赖特定协议。

3.使用摘要算法进行加密

比较容易想到的就是利用不可逆加密散列函数MD5(string)，用户在注册输入密码的时候，就存储MD5(password)值，并且在WEB端先进行MD5(password)，然后将密码传输至后台，与数据库中的密文进行比较（PS：MD5函数在指定位数的情况下，对相同字符串运算值相同）。

优点比较明显：

保证数据库内用户的密码信息安全
在传输过程中只能截取到用户的密文，该密文被MD5加密后无论如何也不能破解
简单高效，执行以及编码难度都不大，各种语言都提供MD5支持，开发快

4.使用非对称加密（RSA加密）

使用RSA密钥对，前端保留公钥文件，服务器后端保留私钥文件，每次登录时，前端使用公钥对密码进行加密，后端使用私钥解密。

不管在什么协议之下，可以看到实际发送的HTTP/HTTPS报文在MD5处理后是这样的:

这样就安全了吗？？？

不是的。因为攻击者并不一定要获取到你的密码明文，如果直接截获你的密码密文，然后发送给服务器不是一样可以登录吗？因为数据库里的不也是MD5(password)的一样的密文吗？HTTP请求被伪造，一样可以登录成功。

5.加上Token令牌 / 验证码

在用户登录之前，服务器缓存生成随机的验证字段（设置有效时间），并发送给客户端。
当客户端用户输入完账号信息，点击登录后，把这个字段一并传给服务器，用于校验。
校验完成后，服务端删除缓存中的验证字段。

每次从服务器中获取认证的token，确实能保证HTTP请求是由前端传回来的了，因为token在每次登陆后都会删除并被重置，会导致黑客尝试重放账号密码数据信息来登陆的时候导致无法成功登陆。

总而言之，就是我拿到了账号以及密码的密文也登陆不了，因为，如果请求不包含后台认证的令牌token，是个非法请求。

总结

低配版用户安全：只对密码进行简单的MD5加密后传给后台。攻击者压根不需要破解出密码的明文，只需要用它截取到的用户名和MD5加密后的密码作为参数然后直接调你网站的登录接口就好了，因为通常登录接口都是完全暴露的（即任何人都可以调用），校验通过后攻击者拿到授权令牌，接下来就可以为所欲为了。

中配版用户安全：非对称加密。使用RSA密钥对，前端保留公钥文件，服务器后端保留私钥文件，每次登录时，前端使用公钥对密码进行加密，后端使用私钥解密，乍一看，这个应该挺安全了，毕竟使用公钥加密后，每次加密后得到的字符串都是不一样的；但是只是不一样，并不是不能用！如果攻击者拿着这个用户名和公钥加密后的密码直接调用你的登录接口，一样能登录成功，并获得授权令牌。
高配版用户安全：Token令牌。用户每次登录时，由服务端生成一个随机密钥对，将公钥返回给前端，私钥保存到服务器，并设置该密钥对的有效期为30分钟（有效时间大家随意），用户登录的时候，要求前端对用户的明文密码进行公钥加密后传给后端，然后后端用私钥对密码进行解密，然后与数据库保存的密码进行匹配，登录成功之后，服务器立即清除这个密钥对。这样即使攻击者拦截到了加密后的密码，并用这个加密后的密码再次伪造登录，也无法成功。