下列认证协议中，基于MD5哈希密码的挑战-响应机制进行身份验证的是()。

免费智能真题库 > 历年试卷 > 网络工程师 > 2023年下半年网络工程师上午试卷综合知识

第8题

知识点：信息加密技术认证身份验证

关键词： MD5 哈希身份验证协议章/节：安全技术与协议

A. NTLM NT局域网管理器

B. MS-CHAP微软挑战-握手认证协议

C. CHAP挑战-握手认证协议

D. PAP密码认证协议

相关试题：保密

更多>

第44题 2020年下半年

34%

以下关于三重DES加密算法的描述中，正确的是（）。

第41题 2019年下半年

50%

下列算法中，不属于公开密钥加密算法的是( )。

第41题 2010年下半年

46%

按照RSA算法，若选两奇数p=5, q=3,公钥e=7,则私钥d为（41)。


知识点讲解
· 信息加密技术 · 认证 · 身份验证

信息加密技术

数据加密原理

一般的数据加密模型如下图所示。在发送端，把明文X用加密算法E和加密密钥K加密，变换成密文Y，即Y=E_K(X)；在接收端利用解密算法D和解密密钥K对密文Y进行解密，得到明文X。

一般的数据加密模型

加／解密函数E和D是公开的，而密钥K是秘密的。在传送过程中，偷听者得到的是无法理解的密文，而他又得不到密钥，这就达到了对第三者保密的目的。

经典加密技术

经典加密方法主要使用了替换加密、换位加密和一次性填充3种加密技术。

（1）替换加密：用一个字母替换另一个字母。

（2）换位加密：按照一定的规律重排字母的顺序。

（3）一次性填充：把明文变为位串，选择一个等长的随机位串作为密码，对二者进行按位异或，得到密文。

现代加密技术

对称密钥加密的发送和接收数据的双方必须使用相同的／对称的密钥对明文进行加密和解密运算。常用的对称加密算法有DES、IDEA、TDEA、AES、RC2、RC4、RC5等。

数据加密标准

数据加密标准（Data Encryption Standard, DES）是20世纪70年代美国联邦注册大会上，美国国家标准局（NBS）公开征集标准密码的算法。

DES属于分组密码体制，它将分组为64位的明文加密成64位的密文；或反之。整个加密过程由16个独立的加密循环构成，每一个循环使用自己的密钥K₁,K₂，…，K₁₆和加密函数。解密使用与加密相同的过程，但顺序与加密相反，从K₁₆开始变换，直至K₁。主密钥为56位，用于生成每轮循环各自的密钥K₁,K₂，…，K₁₆。加密函数是DES加密运算的核心，分为扩展置换（E盒）、S盒置换和后变位（P盒置换）。

DES的加密密钥和解密密钥相同，属于对称密码体制。其安全性依赖于密钥，但目前可利用差分密码分析的思想对其选择明文攻击方法，因此56位的密钥长度的DES原则上不再是安全的。增加密钥长度和采用多重DES的加密是有意义的加强办法。

三重DES

三重DES是指使用两个密钥，执行3次DES算法，如下图所示。其密钥长度是112位。

三重DES加密算法

国际数据加密数据算法

国际数据加密数据算法（International Data Encryption Algorithm， IDEA）是瑞士苏黎世联邦工业大学（ETH）的Xuejia Lai和James L.Massey于1991年提出的。该算法形式上和DES类似，也是使用循环加密方式，把分组为64位的明文加密为64位的密文；或反之。所不同的是，IDEA使用128位的密钥，扩展成52个16位循环密钥，安全性强于DES。若采用强行攻击，对付IDEA将是对付DES工作量的2⁷²=4.7×10²¹倍，因此，它的安全性是比较好的，是目前数据加密中应用较为广泛的一种密码体制。

由于加密密钥和解密密钥都由同一个主密钥派生而来，IDEA仍属于对称密码体制，而且其设计倾向于软件实现，目前尚未找到破译方法。

公开密钥密码体制

公开密钥密码体制也称为非对称密钥加密。每个用户都有一对密钥：公开密钥和私有密钥。公钥对外公开，私钥由个人秘密保存；用其中一把密钥来加密，另一把密钥来解密。虽然秘密密钥（SK）是由公开密钥（PK）决定的，但却不能根据PK计算出SK。公开密钥密码算法原理如下图所示。

公开密钥密码算法

1）RSA算法

此算法的基础是在数论中寻求两个大素数比较简单，而将它们的乘积分解开则极其困难。每个用户有两个密钥：加密密钥PK={e,n｝和解密密钥SK=｛d,n｝。用户把加密密钥公开，使得系统中任何其他用户都可使用，而对解密密钥中的d则保密。N为两个大素数p和q之积（素数p和q一般为100位以上的十进制数），e和d满足一定的关系。攻击者已知e和n时也并不能求出d。

2）其他的公钥加密算法

ElGamal算法也是一种常用的公钥加密算法，它是基于公钥密码体制和椭圆曲线加密体系，既能用于数据加密，也能用于数字签名。

认证

认证又分为实体认证和消息认证两种。实体认证是识别通信对方的身份，防止假冒，可以使用数字签名的方法。消息认证是验证消息在传送或存储过程中有没有被篡改，通常使用报文摘要的方法。

基于共享密钥的认证

如果通信双方有一个共享的密钥，则可以确认对方的真实身份。这种算法依赖于一个双方都信赖的密钥分发中心（Key Distribution Center，KDC），如下图所示，其中的A和B分别代表发送者和接收者，K_A、K_B分别表示A、B与KDC之间的共享密钥。

基于共享密钥的认证协议

认证过程如下：A向KDC发出消息{A，K_A（B，K_S）}，说明自己要与B通信，并指定了与B会话的密钥K_S。注意，这个消息中的一部分（B，K_S）是用K_A加密的，所以第三者不能了解消息的内容。KDC知道了A的意图后就构造了一个消息{K_B（A，K_S）}发给B。B用K_B解密后就得到了A和K_S，然后就可以与A用K_S会话了。

然而，主动攻击者对这种认证方式可能进行重放攻击。例如A代表雇主，B代表银行。第三者C为A工作，通过银行转账取得报酬。如果C为A工作了一次，得到了一次报酬，并偷听和复制了A和B之间就转账问题交换的报文，那么贪婪的C就可以按照原来的次序向银行重发报文2，冒充A与B之间的会话，以便得到第二次、第三次……报酬。在重放攻击中攻击者不需要知道会话密钥K_S，只要能猜测密文的内容对自己有利或是无利就可以达到攻击的目的。

基于公钥的认证

这种认证协议如下图所示。A向B发出E_B（A，R_A），该报文用B的公钥加密。B返回E_A（R_A，R_B，K_S），用A的公钥加密。这两个报文中分别有A和B指定的随机数R_A和R_B，因此能排除重放的可能性。通信双方都用对方的公钥加密，用各自的私钥解密，所以应答比较简单。其中的K_S是B指定的会话键。这个协议的缺陷是假定双方都知道对方的公钥。

基于公钥的认证协议

身份验证

检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。

常见的身份验证漏洞

测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。

. 是否区分公共访问和受限访问。

如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。

. 是否明确服务账户要求。

设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。

①设计是否要求特权最少的账户。

检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。

②应用程序是否要维护服务账户凭据。

如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。

. 如何验证调用者身份。

测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。

①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。

②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。

如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。

③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。

. 如何验证数据库的身份。

如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。

明确下列问题有助于对数据库身份验证进行评价。

①是否使用SQL身份验证。

在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。

如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。

②是否使用进程账户。

如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。

如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。

③是否使用服务账户。

如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。

此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。

④是否考虑使用匿名Internet用户身份。

对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。

⑤是否使用原始用户身份。

如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。

⑥如何保存数据库连接字符串。

如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。

. 是否强制使用强账户管理措施。

如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。

①应用程序是否强制使用强密码。

例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。

②是否限制失败登录的次数。

这样做有助于对抗词典攻击。

③是否在故障发生后公开过多的信息。

确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。

④是否强制定期更改密码。

如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。

⑤是否能在泄露发生时迅速禁用账户。

如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。

⑥应用程序是否记录登录企图。

记录失败的登录企图是检测攻击者试图侵入的有效方法。

题号导航 2023年下半年网络工程师上午试卷综合知识

本试卷我的完整做题情况



	第8题在手机中做本题