《HTTP权威指南》笔记摘要Day9
摘要认证的改进
- 永远不会以明文的方式发送密码
- 可以防止恶意用户捕获并重放认证过程
- 可以有选择地防止对报文内容地篡改
- 防范其他几种常见的攻击方式
摘要认证不是最安全地协议
摘要函数-MD5
将任意长度的字节序列转换为一个128位置的摘要
有时将摘要函数称为加密的校验和,单向散列函数和指纹函数
摘要认证的具体改进
- 用摘要保护密码
- 用随机数防止重攻击
摘要算法的输入数据
- 由单向散列函数H(d)与摘要KD(s,d)组成的一对函数,s表示密码,d表示数据
- 一个包含安全信息的数据块,成为A1
- 一个包含请求报文中非保密属性的数据库,称为A2
A1与安全性相关,A2与报文相关
H和KD处理A1和A2,产生摘要
MD5与MD5-sess
- MD5为每条请求运行单向散列函数。A1是由冒号连接起来的用户名、域个密码的三元组
- MD5-sess中,只在第一次www-Authenticate握手时运行一次散列函数。对用户名、域和密码进行一次CPU密集型散列,并将其放在当前随机数和客户端随机数前面
RFC2617为A2定义的两种策略
- 只包含HTTP请求方法和URL。当qop=“auth”时使用
- 添加报文实体的主体部分,以提供一定程度的报文完整性检测,,当qop="auth-int"时使用
随机数过期
客户端随机数过期后,服务器仍然接收,且返回带有新随机数的401响应,指定这个响应stale = true,让客户端重试这条请求,客户端不需要重新输入密码等信息
预授权
预授权减少了报文的数量
摘要认证中的三种预授权方式
- 服务器预先在Authentication-info成功首部中发送下一个随机数
- 服务器允许在一小段时间内使用同一个随机数
- 客户端和服务器使用同步的,可预测的随机数生成算法
预先生成下一个随机数
缺点:破坏了对同一台服务器多条请求的管道化功能,因为发布下一条请求前,一定要收到收到下一个随机值才行。而管道化时避免延迟的一个基本技术,所以这种做法会造成很大的性能损失
受限的随机数重用机制
缺点:重用随机数会使得攻击者更容易成功实行重放攻击。
虽然这降低了安全性,但重用的随机数生存期时可控的,所以应该可以在安全和性能间找到平衡
同步生成随机数
安全性取决于开发者设计的同步生成随机数算法
随机数的选择
RFC2617 推荐使用的随机数公式:
BASE64(time-stamp H(time-stamp “:” ETag “:” private-key))
对称认证
RFC 2617扩展了摘要认证机制,允许客户端对服务器进行认证。这是通过客户端随机数来实现的,服务器会根据它对共享保密信息真的正确了解生成正确的响应摘要。然后服务器在Authrorization-Info中返回给客户端