Re: [PATCH] use CHAP for dial-in as default

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]

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