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(a)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'};    
> > 
> >