What is the default authentication scheme that performs authentication using a challenge/response strategy?

What is the default authentication scheme that performs authentication using a challenge/response strategy?

• A. Kerberos Authentication
• B. NT LAN Manager (NTLM)
• C. RADIUS
• D. SAML 2.0

Answer: (B)

Challenge/response authentication works by the server sending a random challenge to the client, and the client replying with a value derived from that challenge and the user’s credential. The server then verifies the response using the known credential material. This handshake ensures the actual password is never sent over the network. NTLM is the protocol that uses this exact mechanism. It employs a three-step exchange often described as negotiate, challenge, and authenticate. The server issues a challenge (a nonce), the client computes a response from that challenge and the user’s password-derived hash, and the server validates the response against the expected value stored for the account. This design specifically embodies the challenge/response pattern to prove knowledge of the user's credentials without transmitting the password itself. Other options don’t fit the same pattern. Kerberos uses tickets issued by a trusted authority rather than a challenge/response handshake in the same sense. SAML 2.0 relies on token-based assertions for web single sign-on rather than a challenge/response exchange. RADIUS can support various methods, including some challenge/response approaches like CHAP, but it is not the default Windows-domain authentication scheme that is defined by this challenge/response handshake.

Challenge/response authentication works by the server sending a random challenge to the client, and the client replying with a value derived from that challenge and the user’s credential. The server then verifies the response using the known credential material. This handshake ensures the actual password is never sent over the network.

NTLM is the protocol that uses this exact mechanism. It employs a three-step exchange often described as negotiate, challenge, and authenticate. The server issues a challenge (a nonce), the client computes a response from that challenge and the user’s password-derived hash, and the server validates the response against the expected value stored for the account. This design specifically embodies the challenge/response pattern to prove knowledge of the user's credentials without transmitting the password itself.

Other options don’t fit the same pattern. Kerberos uses tickets issued by a trusted authority rather than a challenge/response handshake in the same sense. SAML 2.0 relies on token-based assertions for web single sign-on rather than a challenge/response exchange. RADIUS can support various methods, including some challenge/response approaches like CHAP, but it is not the default Windows-domain authentication scheme that is defined by this challenge/response handshake.