任县网站建设公司,北京网站开发网站开发公司,烟台网站开发制作,济南家居行业网站开发HTTP协议规范中有两种认证方式#xff0c;一种是Basic认证#xff0c;另外一种是Digest认证#xff0c;这两种方式都属于无状态认证方式#xff0c;所谓无状态即服务端都不会在会话中记录相关信息#xff0c;客户端每次访问都需要将用户名和密码放置报文一同发送给服务端一种是Basic认证另外一种是Digest认证这两种方式都属于无状态认证方式所谓无状态即服务端都不会在会话中记录相关信息客户端每次访问都需要将用户名和密码放置报文一同发送给服务端但这并不表示你在浏览器中每次访问都要自己输入用户名和密码可能是你第一次输入账号后浏览器就保留在内存中供后面的交互使用。 BASIC基本认证 概述 当一个客户端向HTTP服务器进行数据请求时如果客户端未被认证则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证以决定用户是否合法。客户端在接收到HTTP服务器的身份认证要求后会提示用户输入用户名及密码然后将用户名及密码以BASE64加密加密后的密文将附加于请求信息中 如当用户名为chackca密码为123456时客户端将用户名和密码用“”合并并将合并后的字符串用BASE64加密为密文并于每次请求数据时将密文附加于请求头Request Header中。HTTP服务器在每次收到请求包后根据协议取得客户端附加的用户信息BASE64加密的用户名和密码解开请求包对用户名及密码进行验证如果用户名及密码正确则根据客户端请求返回客户端所需要的数据;否则返回错误代码或重新要求客户端提供用户名及密码。 BASIC认证的过程 基本认证步骤 1、客户端访问一个受http基本认证保护的资源。 2、服务器返回401状态要求客户端提供用户名和密码进行认证。验证失败的时候响应头会加上WWW-Authenticate: Basic realm请求域。 401 Unauthorized WWW-Authenticate Basic realmWallyWorld 3、客户端将输入的用户名密码用Base64进行编码后采用非加密的明文方式传送给服务器。Authorization: Basic xxxxxxxxxx. 4、服务器将Authorization头中的用户名密码解码并取出进行验证如果认证成功则返回相应的资源。如果认证失败则仍返回401状态要求重新进行认证。 服务端返回的认证报文中包含了realm”myTomcat”realm的值用于定义保护的区域在服务端可以通过realm将不同的资源分成不同的域域的名称即为realm的值每个域可能会有自己的权限鉴别方案。 Basic认证的一些特点 1、Http是无状态的同一个客户端对同一个realm内资源的每一个访问会被要求进行认证。 2、客户端通常会缓存用户名和密码并和authentication realm一起保存所以一般不需要你重新输入用户名和密码。 3、以非加密的明文方式传输虽然转换成了不易被人直接识别的字符串但是无法防止用户名密码被恶意盗用。虽然用肉眼看不出来但用程序很容易解密。 优点 基本认证的一个优点是基本上所有流行的网页浏览器都支持基本认证。基本认证很少在可公开访问的互联网网站上使用有时候会在小的私有系统中使用如路由器网页管理接口。后来的机制HTTP摘要认证是为替代基本认证而开发的允许密钥以相对安全的方式在不安全的通道上传输。 缺点 虽然基本认证非常容易实现但该方案建立在以下的假设的基础上即客户端和服务器主机之间的连接是安全可信的。特别是如果没有使用SSL/TLS这样的传输层安全的协议那么以明文传输的密钥和口令很容易被拦截。该方案也同样没有对服务器返回的信息提供保护。现存的浏览器保存认证信息直到标签页或浏览器被关闭或者用户清除历史记录。HTTP没有为服务器提供一种方法指示客户端丢弃这些被缓存的密钥。这意味着服务器端在用户不关闭浏览器的情况下并没有一种有效的方法来让用户登出。 什么是Realm Tomcat提供Realm支持。Tomcat使用Realm使某些特定的用户组具有访问某些特定的Web应用的权限而没有权限的用户不能访问这个应用。Tomcat提供了三种不同Realm对访问某个Web应用程序的用户进行相应的验证。 1、JDBCRealm这个Realm将用户信息存在数据库里通过JDBC从数据库中获得用户信息并进行验证。 2、JNDIRealm将用户信息存在基于LDAP等目录服务的服务器里通过JNDI技术从LDAP服务器中获取用户信息并进行验证。 3、MemoryRealm将用户信息存在一个xml文件中对用户进行验证时将会从相应的xml文件中提取用户信息。manager(Tomcat提供的一个web应用程序)应用在进行验证时即使用此种Realm。Realm类似于Unix里面的group。在Unix中一个group对应着系统的一定资源某个group不能访问不属于它的资源。Tomcat用Realm来对不同的应用(类似系统资源)赋给不同的用户(类似group)。没有权限的用户则不能访问这个应用。 DIGEST摘要认证 https://www.cnblogs.com/huey/p/5490759.html 基本认证便捷灵活但极不安全。用户名和密码都是以明文形式传送的也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与 SSL 配合使用。 摘要认证是另一种 HTTP 认证协议它与基本认证兼容但却更为安全。摘要认证试图修复基本认证协议的严重缺陷。具体来说摘要认证进行了如下改动 永远不会以明文方式在网络上发送密码。可以防止恶意用户捕获并重放认证的握手过程。可以有选择地防止对报文内容的篡改。防范其他几种常见的攻击方式。 摘要认证并不是最安全的协议。摘要认证并不能满足安全 HTTP 事务的很多需求。对这些需求来说使用 TLS 和 HTTPS 协议更为合适一些。但摘要认证比它要取代的基本认证强大很多。 a) 客户端请求了某个受保护文档。 b) 在客户端能够证明其知道密码从而确认其身份之前服务器拒绝提供文档。服务器向客户端发起质询询问用户名和摘要形式的密码。 c) 客户端传递了密码的摘要用户输入实际的密码客户端再将这个密码转化为摘要后再发送证明它是知道密码的。服务器知道所有用户的密码因此可以将客户提供的摘要与服务器自己计算得到的摘要进行比较以验证用户是否知道密码。另一方在不知道密码的情况下很难伪造出正确的摘要。 d) 服务器将客户端提供的摘要与服务器内部计算出的摘要进行对比。如果匹配就说明客户端知道密码或者很幸运地猜中了。可以设置摘要函数使其产生很多数字让人不可能幸运地猜中摘要。服务器进行了匹配验证之后会将文档提供给客户端——整个过程都没有在网络上发送密码。 重放攻击 使用摘要就无需以明文形式发送密码了。可以只发送密码的摘要而且可以确信没有哪个恶意用户能轻易地从摘要中解码出原始密码。 但是仅仅隐藏密码并不能避免危险因为即便不知道密码别有用心的人也可以截获摘要并一遍遍地重放给服务器。摘要和密码一样好用。 为防止此类重放攻击的发生服务器可以向客户端发送了一个称为随机数 (nonce) 的特殊令牌这个数会经常发生变化可能是每毫秒或者是每次认证都变化。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去。 在密码中加入随机数就会使摘要随着随机数的每一次变化而变化。记录下的密码摘要只对特定的随机数有效而没有密码的话攻击者就无法计算出正确的摘要这样就可以防止重放攻击的发生。 摘要认证要求使用随机数因为这个小小的重放弱点会使未随机化的摘要认证变得和基本认证一样脆弱。随机数是在 WWW-Authenticate 质询中从服务器传送给客户端。 摘要认证的握手机制简化的摘要认证三步握手机制 (1) 服务器计算出一个随机数。 (2) 服务器将这个随机数放在 WWW-Authenticate 质询报文中与服务器所支持的算法列表一同发往客户端。 (3) 客户端选择一个算法计算出密码和其他数据的摘要。 (4) 客户端将摘要放在一条 Authorization 报文中发回服务器。如果客户端要对服务器进行认证可以发送客户端随机数。 (5) 服务器接收摘要、选中的算法以及支撑数据计算出与客户端相同的摘要。然后服务器将本地生成的摘要与网络传送过来的摘要进行比较验证是否匹配。如果客户端反过来用客户端随机数对服务器进行质询就会创建客户端摘要。服务器可以预先将下一个随机数计算出来提前将其传递给客户端这样下一次客户端就可以预先发送正确的摘要了。 Cookie Auth Cookie认证机制用户输入用户名和密码发起请求服务器认证后给每个Session分配一个唯一的JSESSIONID并通过Cookie发送给客户端。 当客户端发起新的请求的时候将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。默认的当我们关闭浏览器的时候客户端cookie会被删除可以通过修改cookie 的expire time使cookie在一定时间内有效。但是服务器端的session不会被销毁除非通过invalidate或超时。 Token AuthJWT Token Auth优点 减轻服务器压力通过token可以将用户的基本信息(非隐私的比如UserId过期时间生成的随机key等)全部加密签名后放入token中从而服务器端不需要保存用户登录信息大大减轻服务器压力。用户认证完全靠token识别通过签名来保证token没有被修改过只有服务器才知道秘钥比如常见的非对称加密算法是服务器下发的token。支持跨域访问因为服务器并没有保存登录状态完全靠签名的token识别那么另一个网站只要有对应的私钥就可以对token验证前提是传输的用户认证信息通过HTTP头传输更适用CDN: 可以通过内容分发网络请求你服务端的所有资料如javascriptHTML,图片等因为不需要同步服务器上的登录状态信息性能更好: 因为从token中可以获得userId不用查询登录状态表原文https://blog.csdn.net/qq_35642036/article/details/82788588 转载于:https://www.cnblogs.com/NetPig/p/10917282.html
