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

mlessard
Comes here often

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

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

8 Replies 8
jdsilva
Kind of a big deal

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
Comes here often

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
Kind of a big deal

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

 

image.png

PhilipDAth
Kind of a big deal
Kind of a big deal

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
Kind of a big deal

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.

 

image.png

jdsilva
Kind of a big deal

mlessard
Comes here often

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
Kind of a big deal

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.  
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels