[prev in list] [next in list] [prev in thread] [next in thread]
List: ipfire-development
Subject: Re: [PATCH] use CHAP for dial-in as default
From: Peter =?UTF-8?B?TcO8bGxlcg==?= <peter.mueller () link38 ! eu>
Date: 2017-12-04 16:40:05
Message-ID: 20171204174005.7c16f4e4.peter.mueller () link38 ! eu
[Download RAW message or body]
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'};
> >
> >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic