面试官：设计安全登录应该考虑什么？我看，.

作者：letcafe来源：https://www.cnblogs.com/letca...1.一个简单的HTML例子看用户信息安全标准的HTML语法，它支持使用标签创建一个HTTP提交属性。在现代WEB登录中，常见如下形式：用户名：Password:Loginform表单会获取名字提交请求时表单中input标签的属性，在HTTP请求体中作为参数传递给后台进行登录验证。比如我的账号是user1，密码是123456，那么当我提交登录时，发送到后台的HTTP请求如下（通过Chrome或者FireFox开发者工具抓取，需要开启Preservelog）：可以发现，即使密码字段是一个黑点，但是机器还是截获了明文的请求。2、HTTP协议传输直接暴露用户密码字段。在网络传输过程中，如果被嗅探，将直接危及用户信息的安全。以Fiddler或Wireshark为例，发现抓取的HTTP报文中包含敏感信息：3.使用加密算法是否保证密码安全？WEB前端可以通过一定的算法对密码字段进行加密，然后将密码作为Http请求的内容提交。常见的包括对称和非对称加密。对称加密：采用对称密码编码技术，其特点是对文件加密和解密使用相同的密钥加密。非对称加密：需要两个密钥，公钥（publickey）和私钥（privatekey）。公钥和私钥是一对。如果数据是用公钥加密的，只有对应的私钥才能解密；如果数据是用私钥加密的，那么只有对应的公钥才能解密数据。解密。3.1前后端协商后使用对称加密加解密似乎是个好办法。比如前端使用字符串位移+字符串反转的简单方法（比如，当然不能这么简单）。那么，如果把原来的密码123456先移位：123456-->456123，然后反推：456123-->321654，那么这么简单的方法貌似能把原来的密码搞乱，而且反推也能轻松恢复在后台运行。但这有两个缺点：前端加解密需要同时修改代码；前端加密无非就是用JS写的，但是JS有被直接破解识别加密方式的风险。3.2非对称加密的HTTPS就一定安全吗？非对称加密有公钥和私钥的存在。公钥可以随意获取。私钥用于解密公钥。这个原则。但是HTTPS就一定安全吗？HTTP有两个可能的风险：HTTPS可以保证传输过程中的信息不会被他人拦截，但仔细考虑，HTTPS是一个应用层协议，下层使用SSL来保证信息安全，但是在客户端和服务端，密文也可以被拦截；在HTTPS报文传输过程中，如果客户端被恶意引导安装“中间人”WEB信任证书，那么HTTPS中的“中间人攻击”也会将明文密码泄露给其他的。4、结论是无论HTTP还是HTTPS，密码都必须以密文传输。考虑到HTTPS不能保证用户密码信息，应该考虑在应用层之上继续保护密码，即写代码控制。不依赖于特定的协议，更容易想到使用不可逆的加密哈希函数MD5（字符串），当用户注册并输入密码时，存储MD5（密码）值，MD5（密码）是首先在WEB端进行，然后将密码传到后台，与数据库中的密文进行比对（PS：MD5函数对同一个字符串在指定位数的情况下运算值相同）。优点更明显：保证了用户数据库内部密码信息的安全；用户的密文在传输过程中无论如何都不会被破解成原始密码；简单高效，执行和编码不难，MD5提供多种语言支持，开发速度快。5.太好了！这在HTTPS上省了钱，对吧？回到一开始的例子：用户输入的用户名是：user1，密码是：123456，所以无论在什么协议下，可以看到实际发送的HTTP/HTTPS报文是这样的MD5处理后：是，加密登录成功。然而，正当我们庆祝密码安全的时候，却发现账户里的钱突然不见了。为什么是这样？黑客哈哈大笑：因为他们不一定需要得到你的密码明文，如果他们直接截取你的密码密文发送给服务器，不就可以登录了吗？因为数据库中的密文不也和MD5（密码）一样吗？HTTP请求是伪造的，可以登录成功，从而抓取其他数据或转移余额。这个怎么做？其实也不难，解决办法有很多？其实原理都是类似的：就是服务端缓存生成一个随机的校验字段，发送给客户端。当客户端登录时，该字段被传递给服务器进行验证。5.1方案一：验证码MVC场景。控制器会将数据的Model封装到View中。这种连接方式随着Session的存在而允许访问Session中的信息。那么我们可以使用一些开源的验证码生成工具，比如JAVA中的Kaptcha，在服务端存储并生成验证码值和验证码生成图片，将图片进行Base64编码，返回给View，并在ViewBase64中解码并加载图片，下次用户登录时对比。5.2方案二：前后端代币分离。非常流行的前后端分离的开发模式，大大提高了项目的开发效率。职责分工明确，但由于HTTP是无状态的（即本次请求不知道上一次请求的内容），当用户登录时，会生成一个随机的token（如UUID）作为值缓存在Redis中根据用户的用户名作为key，并将token返回给客户端，当客户端登录时，验证完成，并删除Redis中的缓存记录。那么每次从服务端获取认证token，确实可以保证HTTP请求是前端发回的，因为每次登录后token都会被删除和重置，这会导致黑客尝试重放账号登录密码数据信息有时登录不成功。总而言之，即使得到了账号和密码的密文，也无法登录，因为如果请求中不包含后台认证的token，就是非法请求。6.这并不容易！不过也别高兴得太早，小心数据被篡改，密码被加密，黑客看不到明文。有了Token的加入，登录过程就不能再被拦截重放了。但是想想这种情况，你在某宝上进行网上支付，需要账号、密码、金额、token这四个字段进行操作，然后支付的时候，你付了1块钱买了一袋小包包邮的浣熊酥，在某宝结算后，发现账户余额被扣了1万元。这里发生了什么？因为即使黑客不登录不操作，还是会造成破坏：请求路由到黑客的时候，数据包被拦截，就不用登录了，反正账号密码是对的，并且令牌也是正确的。然后数据改包的字段，销毁就好了，所以我把钱改成了10000，然后传给服务器。作为受害者，我无缘无故地踩到了这个坑。但是如何解决呢？其实原理类似于HTTPS中的数字签名机制。首先，什么是数字摘要和数字签名：6.1什么是“数字摘要”我们在下载文件的时候，经常会看到一些下载站点也提供了下载文件的“数字摘要”摘要，供下载者使用验证下载的文件是否完整，或者是否与服务器上的文件“一模一样”。数字摘要其实就是用一个单一的Hash函数，将需要加密的明文“摘要”转换成一串固定长度（128位）的密文，这串密文也叫数字指纹，它的长度是固定的，明文不同，摘要转换成密文的结果总是不同的，但是摘要必须是相同的内容信息相同。因此，将“数字摘要”称为“数字指纹”可能更合适。“数字摘要”是HTTPS能够保证数据完整性和防篡改的根本原因。6.2数字签名——天然的技术如果发送方想向接收方发送消息，在发送消息之前，发送方使用哈希函数从消息文本中生成消息摘要，然后使用他的私钥加密这个摘要，加密后的摘要将作为消息的“签名”与消息一起发送给收件人。接收方首先使用与发送方相同的散列函数提取消息摘要，然后使用发送方的公钥解密附加在消息上的数字签名。如果两个摘要相同，则接收方可以确认消息是从发送方发送的并且没有被遗漏。并修改！这就是将“非对称密钥加解密”和“数字摘要”技术结合起来可以做到的，也就是人们所说的“数字签名”技术。在这个过程中，生成传输数据摘要并用私钥加密的过程就是生成“数字签名”的过程。加密后的数字摘要就是“数字签名”。因此，我们可以在WEB端对上一个案例中提到的username+MD5(password)+token进行签名，得到一个字段checkCode，将checkCode发送给服务器。服务器根据用户和自己发送的校验码对原始数据进行签名。中间通过比对操作确认数据是否被篡改，从而维护数据的完整性。7、小结看似简单的WEB登录，其实存在着很多安全隐患。这些安全完善的流程都是在一个实际的WEB项目中遇到的。以上分析演进是针对项目安全检查提出的解决方案。有很多不足之处。希望大家一起交流探讨，共同进步！补充1：JS加密功能已破解。感谢园丁mysgk指出完整性检查中JS加密函数被破解的问题：问题描述：如果黑客通过阅读前端js源码找到加密算法，是否意味着他可以构造一个可以破解的代码？服务端解密出来的checkCode欺骗服务端呢？想了想，应该是很多网站采用的一种策略：抽象或者加密的JS算法，不直接以静态文件的形式存储在浏览器中，而是让WEB端请求Server，Server可以自己决定根据随机token的token值返回对应的随机加密策略，以JS代码响应的形式返回。在异步请求响应中，加载JS摘要算法，让客户端动态加载数字摘要策略，保证不可伪造。补充2：MD5有隐患。感谢园丁EtherDream指出MD5isoutdatedandinsecure:问题描述：使用MD5和SHA256处理密码已经过时了。..PBKDF和bcrypt现在已过时。本文重点介绍方法思路，不一定要用MD5函数，其他方法也可以。MD5存在隐患。之前真的没想太多，不过还是很感谢园丁指出确实是这样的。大意是：MD5的破解其实就是一个【碰撞】。例如，原文A可以通过MD5生成摘要M。我们不需要将M还原为A，只需要找到原文B，生成相同的摘要M。假设MD5的哈希函数为MD5()，则：MD5(A)=MMD5(B)=MAnyB是破解结果。B可能等于也可能不等于A，大概意思就是如果截获MD5加密后的密文，还是有可能找到不是原始密码但加密后可以登录成功的“伪原文”。由此可见，MD5函数确实可以逆向“破解”，但是这个“破解”只是找一个经过MD5运算得到相同结果的原文，而不是用户的明文密码。不过这种方式登录有可能会被破解。确实有必要使用更完善的算法进行加密。再次感谢！近期热点文章推荐：1.1,000+Java面试题及答案（2021最新版）2.别在满屏的if/else中，试试策略模式，真的很好吃！！3.操！Java中xx≠null的新语法是什么？4、SpringBoot2.5发布，深色模式太炸了！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！