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

2023年下半年上午试卷综合知识

第 8 题


知识点	认证身份验证

A. NTLM NT局域网管理器

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

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

D. PAP密码认证协议

知识点讲解

· 认证

· 身份验证

认证

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

基于共享密钥的认证

如果通信双方有一个共享的密钥，则可以确认对方的真实身份。这种算法依赖于一个双方都信赖的密钥分发中心（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页是否使用正则表达式来验证密码复杂性规则。

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

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

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

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

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

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

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

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

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

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

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5