CHAP::
The user supplies a `CHAP` password attribute.
+
-FreeRADIUS reads the "known good" password from LDAP in cleartext, and
-compares that to what the user entered.
+FreeRADIUS reads the "known good" password from LDAP, and compares
+that to what the user entered. The password in LDAP *must* be clear
+text.
MS-CHAP::
The user supplies a `MS-CHAP` password attribute. Either as
MS-CHAPv2, or as PEAP/MSCHAPv2, or as EAP-TTLS/MS-CHAPv2.
+
-FreeRADIUS reads the "known good" password from LDAP in cleartext, or
-as an NT hash, and compares that to what the user entered.
+FreeRADIUS reads the "known good" password from LDAP, and does the
+relevant MS-CHAP hashing in order to verify the data it received from
+the user. The password in LDAP *must* be clear text, or as an NT hash.
All of these authentication methods except "bind as user" require
that FreeRADIUS obtain the `userPassword` field from LDAP. If that
recommend having the LDAP database return the `userPassword` field to
FreeRADIUS, so that FreeRADIUS can authenticate the user.
-We strongly recommend that the passwords be stored in LDAP as
-cleartext. Otherwise, the only authentication methods that will work
-are PAP and EAP-TTLS/PAP. The next section explains these issues in
-more detail.
+We strongly recommend that the passwords be stored in LDAP as hashed /
+salted. The downside of this approach is that the authentication
+methods are then limited to PAP and EAP-TTLS/PAP. Storing passwords
+as clear text (or NT hash, which is essentially clear text) is
+extremely insecure.
+
+For an in-depth description as to why are making these
+recommendations, see the InkBridge article on
+https://www.inkbridgenetworks.com/blog/blog-10/pap-vs-chap-is-pap-less-secure-55[PAP
+vs CHAP]
// Copyright (C) 2025 Network RADIUS SAS. Licenced under CC-by-NC 4.0.
// This documentation was developed by Network RADIUS SAS.
together. In many cases, a naive approach to LDAP security will
prevent RADIUS from working.
-The issue of a database storing passwords in clear-text has to be
-balanced against the users sending clear-text passwords in
-authentication protocols. While those passwords are protected by TLS
-(EAP-TTLS) or by RADIUS (in it's own "encryption" mechanism), it is
-generally better to use a stronger authentication method than just
-PAP.
+For an in-depth description as to why are making these
+recommendations, see the InkBridge article on
+https://www.inkbridgenetworks.com/blog/blog-10/pap-vs-chap-is-pap-less-secure-55[PAP
+vs CHAP]
-In the end, there is no perfect solution to security requirements.
-The choice may be either to give up on using a particular
-authentication method, or to relax the security requirements on LDAP
-and on password storage. The final decision as to which choice is
-best can only be made by a local administrator.
+We pretty much always recommend using PAP. Despite various claims by
+people online, passwords are _never_ sent "in the clear" in any RADIUS
+packet. If anyone tells you that RADIUS sends passwords "in the
+clear", then they do not understand RADIUS, and they are not a
+security expert.
+
+So the passwords _are_ protected "on the wire", and the only entity
+which sees a clear-text password is the RADIUS server. When the
+passwords are "at rest" in the database, they are encrypted / salted,
+and secure.
+
+The very short version of why we recommend PAP is simple: The odds of
+someone breaking into your RADIUS server and stealing a few passwords
+are _much, much lower_ than the odds of someone breaking into your
+database, and stealing _all_ of the passwords.
projects / thirdparty / freeradius-server.git / commitdiff
