HTTP 基本认证&摘要认证（带你一步步算出摘要）

HTTP的质询/响应认证框架

认证协议与首部

HTTP 通过一组可定制的控制首部，为不同的认证协议提供了一个可扩展框架。

步骤	首部	描述	方法/状态
请求		第一条没有认证信息	GET
质询	WWW-Authenticate	服务器用 401 状态拒绝了请求，说明需要用户提供用户名和密码。	401 Unauthorized
授权	Authorization	客户端重新发出请求，但这一次会附加一个Authorization首部，用来说明认证算法、用户名和密码	GET
成功	Authentication-Info	如果授权证书是正确的，服务器就会将文档返回。	200（基本认证没有此首部）

基本认证

我的这篇博客里面，有对HTTP基本认证的一个示例。

摘要认证

基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式（只用Base64编码进行了扰码，没有任何防止用户攻击的手段）传送的。

摘要认证的改进

摘要认证是另一种 HTTP 认证协议，它试图修复基本认证协议的严重缺陷。具体来说，摘要认证进行了如下改进。

• 永远不会以明文方式在网络上发送密码。
• 可以防止恶意用户捕获并重放认证的握手过程。
• 可以有选择地防止对报文内容的篡改。
• 防范其他几种常见的攻击方式。

网上有很多文章详细介绍了摘要认证，这里我就简单的说明一下摘要认证是什么原理，怎么改进了基本认证的缺陷。

首先基本认证的一个重大缺陷就是在请求中使用了Base64加密来传输了用户名和密码，Base64是对称加密，也就意味着如果有人截获了请求，那么就相当于用户名和密码全部暴露了，这是非常危险的事情。

所以摘要认证的基本原则就是绝不通过网络发送明文密码，而是发送一个密码的摘要信息来取代密码，并且这个摘要信息是不可逆的，也就是我们需要用非对称加密算法来加密。例如md5加密。比如客户端需要加密的信息是hello world，经过md5加密后请求发送的是5eb63bbbe01eeed093cb22bb8f5acdc3这一串密文，任何人截获到这段密文是无法反推回hello world的，然后服务端收到这个密文后。他先去数据库中找到你存储的密文hello world（当然是根据你传过来的未加密的用户名来找的，我们省略了没说），然后服务端也对hello world进行md5加密，对比加密后的字符串和客户端发过来的，当然一样啦，那就验证通过了。

当然，这里会有一个严重的问题，黑客截获了摘要信息和密码一样好用，他只要伪造请求，然后把摘要信息再发给服务端就照样可以为所欲为了。那么怎么办呢？加随机数就可以解决。服务端第一次发一个随机串randomStr给客户端，当然，服务端自己也记下来我发了这个随机串给客户端，然后客户端拿到randomStr后，附在密码后面再执行md5加密，然后再把密文发给服务端。这时候就很好了，服务端也是会先把随机串附在密码后面，然后md5加密得到密文，来和客户端发过来的比较。但是现在即使这个密文被截获了也没用，因为这个密文是根据一个服务端的随机数来生成的，而这个随机数服务端可以设置每次请求或者每一毫秒都不一样，而黑客却无法得知。

示例：

说了这么多，不如举个例子来演示一下摘要是怎么算出来的，这样更容易理解这个东西。下面我就来带大家算一下这个摘要。

这里我用Node起了一个简单的HTTP服务，在/digest上加了一个简单的摘要认证。

if (req.url === '/digest') {
    if (!req.headers['authorization']) {
      // 这里很粗暴，如果客户端请求头中没有`authorization`首部，则直接401请求进行摘要认证，记住这里的`realm`和`qop`和`nonce`，后面计算摘要的时候会用到
      res.writeHead(401, {
        'WWW-Authenticate': 'Digest realm="blog.csdn.net" qop="auth" nonce="C1A5298F939E87E8F962A5EDFC206918"'
      })
      res.end('no permissiion')
    } else {
      res.writeHead(200, {
        'Content-Type': 'text/plain'
      })
      // 如果请求头中有`authorization`首部，则显示出来，便于我们一会儿拿来计算摘要
      res.end(req.headers['authorization'])
    }
  }

1. 打开/digest，弹出密码框，注意realm的信息是会显示出来的，realm直译过来是领域、范围的意思，实际上这个字段是告诉用户这个权限的是用来干嘛的。
   

   

   在这里插入图片描述

2. 然后我们输入用户名admin，密码123456，然后点击确定，这时候客户端会计算好摘要然后放到请求头Authorization首部中再发一次请求。
   

   

   在这里插入图片描述
   
   3.然后上面说了，一旦有这个头部，我就返回200，而且直接返回头部，这下知道为啥要这么做了吧，方便看啊：）
   
   

   在这里插入图片描述
   
   4.好了，下面我们来看一下客户端生成了哪些字段。主要有response、nc和conce三个字段，response字段是最终的摘要。现在我们一起来根据这些字段，手动计算出这个response，这样我们就说明我们可以在服务端进行验证了。
   
   

   在这里插入图片描述
   
   5.首先response的值是7715f35b1e325c9c8952296166d9939c。
   根据摘要算法介绍，我们先得到A1 = ::为admin:blog.csdn.net:123456。A2=:为GET:/digest。
   然后对A1和A2进行md5加密：

   名称	加密前	加密后
   A1	admin:blog.csdn.net:123456	be127d36de3549d7d1e6fa451aef7ce2
   A2	GET:/digest	72c5182fbc56def0cfe368cd32b37c29

   然后根据最后计算摘要的公式MD5(MD5(A1):::::MD5(A2))，我们需要计算be127d36de3549d7d1e6fa451aef7ce2:C1A5298F939E87E8F962A5EDFC206918:00000001:5de05b4c5cedc081:auth:72c5182fbc56def0cfe368cd32b37c29的MD5值，然后来比较和response是否一致。
   

   

   在这里插入图片描述
   
   我们计算出的结果为7715f35b1e325c9c8952296166d9939c。看本条的开头的response值，是不是和我们计算出来的一样呢。

   额外补充一句，每次请求时，nc和cnonce都会变。是不是觉得摘要认证比基本认证要安全很多呢。