"0x" in front of Clear-text password

[Alan DeKok]

On Oct 7, 2021, at 8:40 PM, Eric Aguilar <agueric at gmail.com> wrote:
> We have Freeradius 3 running successfully - we updated from Freeradius 2 a
> couple months ago.

  That's good.  It shows the stability of v2, I guess.

> We encountered a problem with NAS running Coovachilli
> for captive portal authentication which was working before. Even if the
> uamsecret is not set SQL logs the radcheck attempt with the correct
> password but with a leading "0x" - it seems it is rejecting the access
> request due to that 0x being in front.

  I think something else is going on.

> Is there a way to modify freeradius to strip that "0x" so that we can get
> successful authentication or maybe force taking CHAP-Password parameter as
> User-Password?

  I think that's the wrong question.  Let's see.

> Please let me know if I should ask differently or include some more
> information.
> 
> Here is the debug file:
> 
> Ready to process requests
> (0) Received Access-Request Id 60 from 187.168.34.159:48641 to
> 172.31.36.39:1812 length 162
> (0)   User-Name = "06-CC-C6-1E-6B-09"
> (0)   CHAP-Password = 0x7c2e341f7fa12820b2605223bac6c307
> (0)   CHAP-Challenge = 0x047808cb6d147b8d77d3116a0cfa6498

  Here, the CHAP-Password is pretty much MD5(Cleartext-Password + CHAP-Challenge)

  i.e. if you have the *real* password, then the server can calculate CHAP-Password from that, and from the CHAP-Challenge.  It then compares the CHAP-Password it calculated to the one which it sees in the packet.  If they're the same, then the password entered by the user is correct.  If they're different, then the password entered by the user is wrong.

> rlm_sql_mysql: Starting connect to MySQL server
> rlm_sql_mysql: Connected to database 'radius' on
> radiuscg.us-east-2.rds.amazonaws.com via TCP/IP, server version 5.7.33-log,
> protocol version 10

  You should really use TLS and/or IPSec for tht.  But whatever.

> (0) sql: Conditional check items matched, merging assignment check items
> (0) sql:   Cleartext-Password := "7c2e341f7fa12820b2605223bac6c307"

  Uh... that's not right.

  Sure, it's what you put in the database.  But why does the Cleartext-Password have exactly the same hex string as the CHAP-Password?  That should never happen.

  i.e. it only happens if you're reading the packets in debug mode, and assuming that CHAP-Password is actually what the user entered, and then adding that magic hex string to the database.

  Don't do that.  It's extremely wrong.

> (0) pap: No User-Password attribute in the request.  Cannot do PAP

  That's pretty clear.

  Note also that it's not running the "chap" module, which is in the default configuration.  So you've edited the configuration to say "don't do CHAP", and then sent the server a packet which contains CHAP.  That won't work.

  Go back and re-enable the "chap" module.  See the default configuration for where it should go in the "authorize" and "authenticate" sections.

  Then put the REAL Cleartext-Password into the SQL database.  Don't put the random hex stuff from CHAP-Password.  That value will change on every packet.

  And perhaps you could explain a bit more about what you're trying to do.  Why do you think it's necessary to delete "chap" from sites-enabled/default?  And why put the hex string from CHAP-Password into the database as Cleartext-Password?

  What is your end goal here?  If you're trying to authenticate users, just put the real password in the database.  If you're trying to do something else, then explain that.

  Alan DeKok.