Challenge-Handshake Authentication Protocol

<h2 id="benefits-of-chap">Benefits of CHAP</h2>
<p>When the peer sends CHAP, the authentication server will receive it, and obtain the "known good" password from a database, and perform the CHAP calculations.  If the resulting hashes match, then the user is deemed to be authenticated.  If the hashes do not match, then the user's authentication attempt is rejected.
</p><p>Since the authentication server has to store the password in clear-text, it is impossible to use different <a href="/facts/Password/WEoul230">formats for the stored password</a>.  If an attacker were to steal the entire database of passwords, all of those passwords would be visible "in the clear" in the database.
</p><p>As a result, while CHAP can be more secure than PAP when used over a PPP link, it prevents more secure storage "at rest" than with other methods such as <a href="/facts/Password_authentication_protocol/YzWIg2yr">PAP</a>.
</p>
<h2 id="variants">Variants</h2>
<p><a href="/facts/MS-CHAP/ngj5echo">MS-CHAP</a> is similar to CHAP but uses a different hash algorithm, and allows for each party to authenticate the other.
</p>
<h2 id="working-cycle">Working cycle</h2>
<p>CHAP is an authentication scheme originally used by <a href="/facts/Point-to-Point_Protocol/XLaU6D71">Point-to-Point Protocol</a> (PPP) servers to validate the identity of remote clients. CHAP periodically verifies the identity of the <a href="/facts/Client_(computing)/u0wlVsWI">client</a> by using a <a href="/facts/Handshake_(computing)/fqKIh1VW">three-way handshake</a>. This happens at the time of establishing the initial <a href="/facts/Link_Control_Protocol/WkSzWDjE">link (LCP)</a>, and may happen again at any time afterwards. The verification is based on a <a href="/facts/Shared_secret/ATRz7LXy">shared secret</a> (such as the client's password).<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a>
</p>
<ol><li>After the completion of the link establishment phase, the authenticator sends a "challenge" message to the peer.</li>
<li>The peer responds with a value calculated using a <a href="/facts/One-way_function/rGtcumDW">one-way hash function</a> on the challenge and the secret combined.</li>
<li>The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authenticator acknowledges the authentication; otherwise it should terminate the connection.</li>
<li>In PPP, the authenticator may send a new challenge at random intervals to the peer and repeats steps 1 through 3.  However, when CHAP is used in most situations (e.g. <a href="/facts/RADIUS/NfNur5Q5">RADIUS</a>), this step is not performed.</li></ol>
<h2 id="chap-packets">CHAP packets</h2>
<table><tbody><tr><th>Description</th><th>1 byte</th><th>1 byte</th><th>2 bytes</th><th>1 byte</th><th>Variable</th><th>Variable</th></tr><tr><td>Challenge</td><td>Code = 1</td><td>ID</td><td>Length</td><td>Challenge length</td><td>Challenge value</td><td>Name</td></tr><tr><td>Response</td><td>Code = 2</td><td>ID</td><td>Length</td><td>Response length</td><td>Response value</td><td>Name</td></tr><tr><td>Success</td><td>Code = 3</td><td>ID</td><td>Length</td><td></td><td>Message</td><td></td></tr><tr><td>Failure</td><td>Code = 4</td><td>ID</td><td>Length</td><td></td><td>Message</td><td></td></tr></tbody></table>
<p>The ID chosen for the random challenge is also used in the corresponding response, success, and failure packets. A new challenge with a new ID must be different from the last challenge with another ID. If the success or failure is lost, the same response can be sent again, and it triggers the same success or failure indication. For <a href="/facts/MD5/8WIXb9Dq">MD5</a> as hash the response value is MD5(ID||secret||challenge), the MD5 for the concatenation of ID, secret, and challenge.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a>
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/List_of_authentication_protocols/pcX97lnA">List of authentication protocols</a></li>
<li><a href="/facts/Password_Authentication_Protocol/YzWIg2yr">Password Authentication Protocol</a></li>
<li><a href="/facts/Challenge%25E2%2580%2593response_authentication/QTMRmhpM">Challenge–response authentication</a></li>
<li><a href="/facts/Cryptographic_hash_function/cuxkgbST">Cryptographic hash function</a></li></ul>

<h2 id="external-links">External links</h2>

Wikibooks has a book on the topic of: <i>Network Plus Certification/Security/User Authentication</i>

<ul><li><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc1994">1994</a> PPP Challenge Handshake Authentication Protocol (CHAP)</li>
<li><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc2865">2865</a> Remote Authentication Dial In User Service (<a href="/facts/RADIUS/NfNur5Q5">RADIUS</a>): <i>uses <a href="/facts/Password_authentication_protocol/YzWIg2yr">PAP</a> or CHAP</i></li>
<li><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc3748">3748</a> Extensible Authentication Protocol (<a href="/facts/Extensible_Authentication_Protocol/yuCAFHxC">EAP</a>): <i>discusses CHAP</i></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Forouzan (2007). Data Communications & Networking 4E Sie. McGraw-Hill Education (India) Pvt Limited. pp. 352–. ISBN 978-0-07-063414-5. Retrieved 24 November 2012. <a href="978-0-07-063414-5" target="_blank">978-0-07-063414-5</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>"Understanding and Configuring PPP CHAP Authentication". Cisco tech note. 2005. Retrieved 2011-08-14. <a href="http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml" target="_blank">http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
</ol>

Challenge-Handshake Authentication Protocol open-in-new

Challenge-Handshake Authentication Protocol