use CHAP for dial-in as default

  Use CHAP as default setting for PPPoE dial-in connections.

Although CHAP does not provide strong transport security
at all, it is better than submitting credentials in plain text.

Enforcing CHAP prevents the system from silently falling
down to no encryption (MITM attack!).

Existing installations remain untouched.

Signed-off-by: Peter Müller <peter.mueller@link38.eu>
---
 html/cgi-bin/pppsetup.cgi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Hi,

I am not really sure if this would improve security - although the protocol
itself would of course.

Do we know how compatible other ISPs are with CHAP? I know at least one that
only supports CHAP and so we would break compatibility with them since it is
probably not very obvious.

So, in practice I do not think that this change is worth it, because:

a) it might break compatibility. pppd will always use CHAP if it is available
already and fall back to PAP when necessary.

b) CHAP is not really secure. It is some sort of HMAC-MD5, but the challenge is
usually known for someone who can eavesdrop on the wire. So brute-forcing the
password is easy to do. We would only be left with the protection against
immediate replay attacks which I do not consider a problem since ISPs will
suspend your account very quickly.

c) The Internet connection is a public thing. The user credentials are easy to
socially engineer. Even if the authentication would use CHAP this won't improve
any security of the data being transferred after that.

Best,
-Michael

On Sun, 2017-11-19 at 14:47 +0100, Peter Müller wrote:
> Use CHAP as default setting for PPPoE dial-in connections.
> 
> Although CHAP does not provide strong transport security
> at all, it is better than submitting credentials in plain text.
> 
> Enforcing CHAP prevents the system from silently falling
> down to no encryption (MITM attack!).
> 
> Existing installations remain untouched.
> 
> Signed-off-by: Peter Müller <peter.mueller@link38.eu>
> ---
>  html/cgi-bin/pppsetup.cgi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/html/cgi-bin/pppsetup.cgi b/html/cgi-bin/pppsetup.cgi
> index 4b45ee50c..a96dce9df 100644
> --- a/html/cgi-bin/pppsetup.cgi
> +++ b/html/cgi-bin/pppsetup.cgi
> @@ -1042,7 +1042,7 @@ sub initprofile
>          $pppsettings{'HOLDOFF'} = 30;
>          $pppsettings{'TIMEOUT'} = 15;
>          $pppsettings{'MODULATION'} = 'AUTO';
> -        $pppsettings{'AUTH'} = 'pap-or-chap';
> +        $pppsettings{'AUTH'} = 'chap';
>          $pppsettings{'DNS'} = 'Automatic';
>          $pppsettings{'DEBUG'} = 'off';
>          $pppsettings{'BACKUPPROFILE'} = $pppsettings{'PROFILE'};
  

Hello,

> Hi,
> 
> I am not really sure if this would improve security - although the protocol
> itself would of course.
> 
> Do we know how compatible other ISPs are with CHAP? I know at least one that
> only supports CHAP and so we would break compatibility with them since it is
> probably not very obvious.
I am afraid I did not get this. If the ISP supports CHAP only, everything is
fine, isn't it?

Of course, they are certainly ISPs which do not support CHAP at all. But since
existing installations are not changes, this does not break running systems.

The main intention of this patch is to make the user be aware of this issue
- they would need to actively select PAP or PAP/CHAP. It is like saying: "Yes,
you can do so, but this is insecure. Don't say you haven't been warned."
> 
> So, in practice I do not think that this change is worth it, because:
> 
> a) it might break compatibility. pppd will always use CHAP if it is available
> already and fall back to PAP when necessary.
True. The point here was to prevent a system from silently falling back to
plaintext without anybody knowing it - even though a MITM attack against the PPPoE
login credentials is somewhat hypothetical.
> 
> b) CHAP is not really secure. It is some sort of HMAC-MD5, but the challenge is
> usually known for someone who can eavesdrop on the wire. So brute-forcing the
> password is easy to do. We would only be left with the protection against
> immediate replay attacks which I do not consider a problem since ISPs will
> suspend your account very quickly.
In some way, this is opportunistic encryption (again :-| ): CHAP is undoubtedly
broken, but everything - even a base64 encoding - is better than plaintext.

Needless to say, I definitive prefer strong (and enforced) encryption, but in
some scenarios, they are simply not available at the moment.
> 
> c) The Internet connection is a public thing. The user credentials are easy to
> socially engineer. Even if the authentication would use CHAP this won't improve
> any security of the data being transferred after that.
True. But preventing against social engineering is out of the range of IPFire. :-)

Feel free to drop this patch if it doesn't suit. :-)

Best regards,
Peter Müller
> 
> Best,
> -Michael
> 
> On Sun, 2017-11-19 at 14:47 +0100, Peter Müller wrote:
> > Use CHAP as default setting for PPPoE dial-in connections.
> > 
> > Although CHAP does not provide strong transport security
> > at all, it is better than submitting credentials in plain text.
> > 
> > Enforcing CHAP prevents the system from silently falling
> > down to no encryption (MITM attack!).
> > 
> > Existing installations remain untouched.
> > 
> > Signed-off-by: Peter Müller <peter.mueller@link38.eu>
> > ---
> >  html/cgi-bin/pppsetup.cgi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/html/cgi-bin/pppsetup.cgi b/html/cgi-bin/pppsetup.cgi
> > index 4b45ee50c..a96dce9df 100644
> > --- a/html/cgi-bin/pppsetup.cgi
> > +++ b/html/cgi-bin/pppsetup.cgi
> > @@ -1042,7 +1042,7 @@ sub initprofile
> >          $pppsettings{'HOLDOFF'} = 30;
> >          $pppsettings{'TIMEOUT'} = 15;
> >          $pppsettings{'MODULATION'} = 'AUTO';
> > -        $pppsettings{'AUTH'} = 'pap-or-chap';
> > +        $pppsettings{'AUTH'} = 'chap';
> >          $pppsettings{'DNS'} = 'Automatic';
> >          $pppsettings{'DEBUG'} = 'off';
> >          $pppsettings{'BACKUPPROFILE'} = $pppsettings{'PROFILE'};
  

Hi,

On Mon, 2017-11-20 at 19:30 +0100, Peter Müller wrote:
> Hello,
> 
> > Hi,
> > 
> > I am not really sure if this would improve security - although the protocol
> > itself would of course.
> > 
> > Do we know how compatible other ISPs are with CHAP? I know at least one that
> > only supports CHAP and so we would break compatibility with them since it is
> > probably not very obvious.
> 
> I am afraid I did not get this. If the ISP supports CHAP only, everything is
> fine, isn't it?
> 
> Of course, they are certainly ISPs which do not support CHAP at all. But since
> existing installations are not changes, this does not break running systems.
> 
> The main intention of this patch is to make the user be aware of this issue
> - they would need to actively select PAP or PAP/CHAP. It is like saying: "Yes,
> you can do so, but this is insecure. Don't say you haven't been warned."

Well, I think we have a very similar problem like we had last week and it is
convenience & compatibility over security. We have to have a better way to
decide these things.

100% security would be nice but makes the product unusable for probably 100% of
the user base. If we compromise on some things and chose defaults that are
inconvenient for 5% of users, we still have 100% security for 95% of the users.

Maybe a rule like that can work... But that would be a different discussion we
shouldn't have right here.

> > So, in practice I do not think that this change is worth it, because:
> > 
> > a) it might break compatibility. pppd will always use CHAP if it is
> > available
> > already and fall back to PAP when necessary.
> 
> True. The point here was to prevent a system from silently falling back to
> plaintext without anybody knowing it - even though a MITM attack against the
> PPPoE
> login credentials is somewhat hypothetical.

A MITM is less than that. It is unpractical and even if it was feasible there is
not much gain in getting access to the login credentials.

The traffic that is being transferred over the connection itself is way more
interesting and exploitable.

> > b) CHAP is not really secure. It is some sort of HMAC-MD5, but the challenge
> > is
> > usually known for someone who can eavesdrop on the wire. So brute-forcing
> > the
> > password is easy to do. We would only be left with the protection against
> > immediate replay attacks which I do not consider a problem since ISPs will
> > suspend your account very quickly.
> 
> In some way, this is opportunistic encryption (again :-| ): CHAP is
> undoubtedly
> broken, but everything - even a base64 encoding - is better than plaintext.

No, that is security by obscurity and just because it is harder to read for a
human it is not for a machine. It is precisely the same problem with or without
encoding to base64.

> Needless to say, I definitive prefer strong (and enforced) encryption, but in
> some scenarios, they are simply not available at the moment.

I guess what you are looking for is a transport encryption over the Internet
link.

ISPs use IPsec because they don't trust their own infrastructure. That would be
a nice to have but unfortunately nothing we can go after.

> > 
> > c) The Internet connection is a public thing. The user credentials are easy
> > to
> > socially engineer. Even if the authentication would use CHAP this won't
> > improve
> > any security of the data being transferred after that.
> 
> True. But preventing against social engineering is out of the range of IPFire.
> :-)

Yes.

Point is, that the login credentials are a public thing any ways. Some ISPs just
use the same or random credentials for everyone (especially with LTE). Some
others use the customers account number which is on every letter...

> Feel free to drop this patch if it doesn't suit. :-)

I didn't say that (yet). I just voiced my concerns. :)

-Michael

> 
> Best regards,
> Peter Müller
> > 
> > Best,
> > -Michael
> > 
> > On Sun, 2017-11-19 at 14:47 +0100, Peter Müller wrote:
> > > Use CHAP as default setting for PPPoE dial-in connections.
> > > 
> > > Although CHAP does not provide strong transport security
> > > at all, it is better than submitting credentials in plain text.
> > > 
> > > Enforcing CHAP prevents the system from silently falling
> > > down to no encryption (MITM attack!).
> > > 
> > > Existing installations remain untouched.
> > > 
> > > Signed-off-by: Peter Müller <peter.mueller@link38.eu>
> > > ---
> > >  html/cgi-bin/pppsetup.cgi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/html/cgi-bin/pppsetup.cgi b/html/cgi-bin/pppsetup.cgi
> > > index 4b45ee50c..a96dce9df 100644
> > > --- a/html/cgi-bin/pppsetup.cgi
> > > +++ b/html/cgi-bin/pppsetup.cgi
> > > @@ -1042,7 +1042,7 @@ sub initprofile
> > >          $pppsettings{'HOLDOFF'} = 30;
> > >          $pppsettings{'TIMEOUT'} = 15;
> > >          $pppsettings{'MODULATION'} = 'AUTO';
> > > -        $pppsettings{'AUTH'} = 'pap-or-chap';
> > > +        $pppsettings{'AUTH'} = 'chap';
> > >          $pppsettings{'DNS'} = 'Automatic';
> > >          $pppsettings{'DEBUG'} = 'off';
> > >          $pppsettings{'BACKUPPROFILE'} = $pppsettings{'PROFILE'};  
> 
>
  

Hello,

sorry for the late reply.

> Hi,
> 
> On Mon, 2017-11-20 at 19:30 +0100, Peter Müller wrote:
> > Hello,
> >   
> > > Hi,
> > > 
> > > I am not really sure if this would improve security - although the protocol
> > > itself would of course.
> > > 
> > > Do we know how compatible other ISPs are with CHAP? I know at least one that
> > > only supports CHAP and so we would break compatibility with them since it is
> > > probably not very obvious.  
> > 
> > I am afraid I did not get this. If the ISP supports CHAP only, everything is
> > fine, isn't it?
> > 
> > Of course, they are certainly ISPs which do not support CHAP at all. But since
> > existing installations are not changes, this does not break running systems.
> > 
> > The main intention of this patch is to make the user be aware of this issue
> > - they would need to actively select PAP or PAP/CHAP. It is like saying: "Yes,
> > you can do so, but this is insecure. Don't say you haven't been warned."  
> 
> Well, I think we have a very similar problem like we had last week and it is
> convenience & compatibility over security. We have to have a better way to
> decide these things.
Basically yes, but this often depends on the actual problem, so I fear there is
no general way to handle this balance between security and usability/compatibility.
> 
> 100% security would be nice but makes the product unusable for probably 100% of
> the user base. If we compromise on some things and chose defaults that are
> inconvenient for 5% of users, we still have 100% security for 95% of the users.
> 
> Maybe a rule like that can work... But that would be a different discussion we
> shouldn't have right here.
I agree.
> 
> > > So, in practice I do not think that this change is worth it, because:
> > > 
> > > a) it might break compatibility. pppd will always use CHAP if it is
> > > available
> > > already and fall back to PAP when necessary.  
> > 
> > True. The point here was to prevent a system from silently falling back to
> > plaintext without anybody knowing it - even though a MITM attack against the
> > PPPoE
> > login credentials is somewhat hypothetical.  
> 
> A MITM is less than that. It is unpractical and even if it was feasible there is
> not much gain in getting access to the login credentials.
> 
> The traffic that is being transferred over the connection itself is way more
> interesting and exploitable.
> 
> > > b) CHAP is not really secure. It is some sort of HMAC-MD5, but the challenge
> > > is
> > > usually known for someone who can eavesdrop on the wire. So brute-forcing
> > > the
> > > password is easy to do. We would only be left with the protection against
> > > immediate replay attacks which I do not consider a problem since ISPs will
> > > suspend your account very quickly.  
> > 
> > In some way, this is opportunistic encryption (again :-| ): CHAP is
> > undoubtedly
> > broken, but everything - even a base64 encoding - is better than plaintext.  
> 
> No, that is security by obscurity and just because it is harder to read for a
> human it is not for a machine. It is precisely the same problem with or without
> encoding to base64.
> 
> > Needless to say, I definitive prefer strong (and enforced) encryption, but in
> > some scenarios, they are simply not available at the moment.  
> 
> I guess what you are looking for is a transport encryption over the Internet
> link.
> 
> ISPs use IPsec because they don't trust their own infrastructure. That would be
> a nice to have but unfortunately nothing we can go after.
> 
> > > 
> > > c) The Internet connection is a public thing. The user credentials are easy
> > > to
> > > socially engineer. Even if the authentication would use CHAP this won't
> > > improve
> > > any security of the data being transferred after that.  
> > 
> > True. But preventing against social engineering is out of the range of IPFire.
> > :-)  
> 
> Yes.
> 
> Point is, that the login credentials are a public thing any ways. Some ISPs just
> use the same or random credentials for everyone (especially with LTE). Some
> others use the customers account number which is on every letter...
> 
> > Feel free to drop this patch if it doesn't suit. :-)  
> 
> I didn't say that (yet). I just voiced my concerns. :)
Well, to sum it up, I did not see most points above. In my eyes the patch creates
more problems than it solves and can be dropped.

Best regards,
Peter Müller
> 
> -Michael
> 
> > 
> > Best regards,
> > Peter Müller  
> > > 
> > > Best,
> > > -Michael
> > > 
> > > On Sun, 2017-11-19 at 14:47 +0100, Peter Müller wrote:  
> > > > Use CHAP as default setting for PPPoE dial-in connections.
> > > > 
> > > > Although CHAP does not provide strong transport security
> > > > at all, it is better than submitting credentials in plain text.
> > > > 
> > > > Enforcing CHAP prevents the system from silently falling
> > > > down to no encryption (MITM attack!).
> > > > 
> > > > Existing installations remain untouched.
> > > > 
> > > > Signed-off-by: Peter Müller <peter.mueller@link38.eu>
> > > > ---
> > > >  html/cgi-bin/pppsetup.cgi | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/html/cgi-bin/pppsetup.cgi b/html/cgi-bin/pppsetup.cgi
> > > > index 4b45ee50c..a96dce9df 100644
> > > > --- a/html/cgi-bin/pppsetup.cgi
> > > > +++ b/html/cgi-bin/pppsetup.cgi
> > > > @@ -1042,7 +1042,7 @@ sub initprofile
> > > >          $pppsettings{'HOLDOFF'} = 30;
> > > >          $pppsettings{'TIMEOUT'} = 15;
> > > >          $pppsettings{'MODULATION'} = 'AUTO';
> > > > -        $pppsettings{'AUTH'} = 'pap-or-chap';
> > > > +        $pppsettings{'AUTH'} = 'chap';
> > > >          $pppsettings{'DNS'} = 'Automatic';
> > > >          $pppsettings{'DEBUG'} = 'off';
> > > >          $pppsettings{'BACKUPPROFILE'} = $pppsettings{'PROFILE'};    
> > 
> >