Sign-on splash page with radius server - communication not encrypted?

[mlessard]

Hello,

We are trying to use the sign-on splash page using our own radius server. The authentication works well.

My question is - the communication between the client and Meraki is encrypted since the Meraki splash page is secured with SSL.

However from what I understand the requests made by the Meraki cloud to our RADIUS server does not seem to be encrypted? Password are sent via PAP in plain text? Isn't this a security risk?

Thanks

[jdsilva]

RADIUS by definition is not encrypted. But, passwords should be hashed, not sent clear text...

I have never sniffed the traffic. Sounds like I should. I would say this is a security risk and should be fixed if true.

[mlessard]

The requests that my radius server receives from the Meraki cloud contain the password (no hash) and the authentication is done via PAP, so this is insecure unless I'm mistaken.

The communication between the Meraki cloud and a radius server would have to be secured using EAP somehow if we want this to be secure, right?

[jdsilva]

Hmmm, I don't see the password in clear text, only the user.

[PhilipDAth]

Passwords are sent in clear TXT, correct.  There have been efforts to resolve this for other technologies like WiFi which allows PEAP, EAP-TLS, EAP-TTLS - but there is no way to do this for a portal login.

[jdsilva]

I'm not seeing what you guys are talking about. My first example up there was using the test button on the radius server config for the SSID. Here's another from actually entering the creds into the splash page. The pass is not in clear text.

[jdsilva]

[mlessard]

I just tested using tcpdump like you did. You're right the password is not passed in plain text, however try running freeradius in debug mode and you will see the unhashed password in the User-Password attribute of the request. I think Meraki simply XORs the password with the freeradius server secret, which is better than nothing, but still very insecure.

As I suspected it is using PAP, see https://wiki.freeradius.org/glossary/PAP

[jdsilva]

https://tools.ietf.org/html/rfc2865#section-5.2

      On transmission, the password is hidden.  The password is first
      padded at the end with nulls to a multiple of 16 octets.  A one-
      way MD5 hash is calculated over a stream of octets consisting of
      the shared secret followed by the Request Authenticator.  This
      value is XORed with the first 16 octet segment of the password and
      placed in the first 16 octets of the String field of the User-
      Password Attribute.

      If the password is longer than 16 characters, a second one-way MD5
      hash is calculated over a stream of octets consisting of the
      shared secret followed by the result of the first xor.  That hash
      is XORed with the second 16 octet segment of the password and
      placed in the second 16 octets of the String field of the User-
      Password Attribute.

      If necessary, this operation is repeated, with each xor result
      being used along with the shared secret to generate the next hash
      to xor the next segment of the password, to no more than 128
      characters.

      The method is taken from the book "Network Security" by Kaufman,
      Perlman and Speciner [9] pages 109-110.