- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
HTTP通信中常见认证方式安全性分析
HTTP通信中常见认证方式安全性分析
摘要
随着互联网与更多传统行业的深度融合发展,网络应用中需要进行认证的场景越来越多,保证此过程的安全尤为重要。以下本文介绍了HTTP通信中常见的几种认证方式的原理并对其各自的安全性进行了分析。
【关键词】认证方式 通信安全 加密过程
1前言
随着互联网行业的不断发展,电子商务,电子银行等传统行业与互联网结合的越来越紧密,这些行业都深度涉及用户的财产和隐私,对安全性要求很高。近年来针对这些网络业务的网络欺骗和欺诈也层出不穷,因此有必要对网络通信的安全引起足够重视。以下,本文将着重对目前HTTP通信中常见认证方式的原理和安全性进行分析。
2BASIC认证
BASIC基本认证是在HTTP1.0中所采用的一种认证方式,它要求客户端将输入的认证信息(用户名和密码)经过BASE64编码后发送给服务器,服务器加以验证并以结果辨别确认客户端身份。BASE64编码按6bit识别,转换过程是将用户名密码等字段以6位二进制重新划分,分完若有不足6位的加0?理,并据此用BASE64编码表重新编码,服务器段据此解码并与用户数据加以比较。BASE64只是一种编码方式,没有进行加密,它简单明了,但有安全性的问题,主要有几点:
(1)BASIC认证是用base64对用户名和密码进行简单的编码后发送的,如上文所言,base64非常容易被解码,可以看做是明文发送,这风险极大。
(2)即使不解码,窃听者也可以获得用户名和密码的密文,并转发给原始服务器,以获得对服务器的访问权。
(3)BASIC认证没有提供完整性保护,窃听者可以任意修改报文。
(4)BASIC对通信双方没有认证过程,即双方都无法确认身份。
3DIGEST认证
DIGEST认证可以看作是BASIC认证的改良方案。它的基本流程和BASIC相似,只是并不传送用户名密码等直接信息,DIGEST采用将服务器端和客户端在通信过程中各自生成的随机值与用户名密码等敏感信息混合在一起计算MD5值,并在信道里传送此MD5值的方法避免密码明文传送。从安全性上考虑,DIGEST可以比较有效的保证通信安全。它主要有以下特点:
(1)通过传递用户名,密码等计算出来的摘要来解决明文传输密码的问题。
(2)通过产生随机数nonce并设置生存期,在通信中检查报文中的nonce值,一旦超时即丢弃报文,同时在客户端发出的报文中设置了nc值,nc值要求每次都要比之前那次更大一些,假如第一次报文HC值是1,则第二次报文中nc须大于1,通信过程中服务器检查nc值,一旦相同则丢弃,通过这些设计可以有效的防止重放攻击。
(3)DIGEST认证中有检查完整性的字段qop,当客户端的响应报文中qop值设为auth-int时即进行完整性校验。
但是,摘要认证并不是最安全的协议,它有以下问题:1.它不对通信双方进行身份认证,难以避免身份伪装和欺骗,且使用上不够灵活,仍达不到一些网站对安全性的要求。
4SSL认证
SSL是目前被广泛使用的认证协议,用在HTTPS(HTTP Secure)中通信双方身份认证及密钥分发的场景较多。通信安全首先应该保证通信双方的身份,这在SSL认证中通过证书机制得以确认。首先服务器方向第三方数字证书认证机构(CA Certificate Authority)申请公钥证书并购买客户端数字证书。之后服务方将数字证书出售或赠与给需要验证身份的客户,双方据证书进行交互,证书申请和交互过程具体如下:
(1)HTTPS服务器方向数字证书认证机构CA提出公开密钥的申请。
(2)CA对申请者提供的信息进行审核,审核通过后,CA会对己申请的公开密钥做数字签名,将该公开密钥与公钥证书进行绑定,然后分配这个证书给申请者。
(3)每当有客户端发起HTTPS请求时,服务器会将这份公钥证书发送给客户端,以进行公开密钥加密方式通信。如果客户端提出的资源需要验证客户端的身份,服务器也会发送Certificate Request报文,要求客户端提供证书。
(4)接到证书的客户端使用CA的公开密钥,对那张证书上的数字签名进行验证,一旦验证通过,客户端便可明确两件事:1.认证服务器的公开密钥的是真实有效的CA。2.服务器的公开密钥是值得信赖的。如果服务器要求提供证书,客户端会把客户端证书信息以Client Certificate报文发送给服务器。
CA的公开密钥必须安全地转交给客户端。在传输过程中要做到这点很难,因此多数浏览器会事先植入常用CA的公开密钥。
(5)双方通过认证后开始通信。经过以上过程,便可以确信双方的身份,但这里存在前提,CA的身份和证书绝对可靠。CA作为中介解决
文档评论(0)