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

[Michael Tremer <michael.tremer@ipfire.org>]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]