宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

（1）HTTP常见认证机制 和 https 　　（2）BASE64编码介绍

Http定义了两个官方认证：基本认证（Basic认证）和摘要认证

BASIC认证的过程

基本认证步骤：
1、客户端访问一个受http基本认证保护的资源。
2、服务器返回401状态，要求客户端提供用户名和密码进行认证。（验证失败的时候，响应头会加上WWW-Authenticate: Basic realm=“请求域”。）
401 Unauthorized
WWW-Authenticate： Basic realm=“WallyWorld”
3、客户端将输入的用户名密码用Base64进行编码后，采用非加密的明文方式传送给服务器。
Authorization: Basic xxxxxxxxxx.
4、服务器将Authorization头中的用户名密码解码并取出，进行验证，如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

用户名/密码经过Base64加码后，这个Base64码值可以轻易被解码并获得用户名/密码，所以此认证方式并不安全。为了传输安全，需要配合SSL使用

摘要认证

digest authentication（HTTP1.1提出的基本认证的替代方法）
这个认证可以看做是基本认证的增强版本，不包含密码的明文传递。

不以明文发送密码，在上述第2步时服务器响应返回随机字符串nonce
而客户端发送响应摘要 =MD5HA1:nonce:HA2)，其中HA1=MD5username:realm:password),HA2=MD5method:digestURI)
在 HTTP 摘要认证中使用 MD5 加密是为了达成"不可逆的"，也就是说，当输出已知的时候，确定原始的输入应该是相当困难的。
如果密码本身太过简单，也许可以通过尝试所有可能的输入来找到对应的输出（穷举攻击），甚至可以通过字典或者适当的查找表加快查找速度。

HTTP摘要认证的安全性增强如下：
1 密码并非直接在摘要中使用，而是 HA1 = MD5username:realm:password)。这就允许一些实现（如，JBoss DIGESTAuth)仅存储 HA1 而不是明文密码。
2 在 RFC 2617 中引入了客户端随机数 nonce，这将使客户端能够防止选择明文攻击（否则，像Rainbow table这类东西就会成为摘要认证构架的威胁）。
3 服务器随机数 nonce 允许包含时间戳。因此服务器可以检查客户端提交的随机数 nonce，以防止重放攻击。
4 服务器也可以维护一个最近发出或使用过的服务器随机数nonce的列表以防止重用。

在安全性方面，摘要访问认证有几个缺点：
1 RFC 2617 中的许多安全选项都是可选的。如果服务器没有指定保护质量qop)，客户端将以降低安全性的早期的 RFC 2069 的模式操作。
2 摘要访问认证容易受到中间人攻击。举例而言，一个中间人攻击者可以告知客户端使用基本访问认证或早期的RFC 2069摘要访问认证模式。
进一步而言，摘要访问认证没有提供任何机制帮助客户端验证服务器的身份。
一些服务器要求密码以可逆加密算法存储。但是，仅存储用户名、realm、和密码的摘要是可能的。[2]
它阻止了使用强密码哈希函数（如bcrypt）保存密码（因为无论是密码、或者用户名、realm、密码的摘要都要求是可恢复的）。