From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] use CHAP for dial-in as default Date: Tue, 21 Nov 2017 12:25:25 +0000 Message-ID: <1511267125.4838.572.camel@ipfire.org> In-Reply-To: <20171120193005.00783c00.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2039509038034361757==" List-Id: --===============2039509038034361757== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, 2017-11-20 at 19:30 +0100, Peter M=C3=BCller wrote: > Hello, >=20 > > Hi, > >=20 > > I am not really sure if this would improve security - although the protoc= ol > > itself would of course. > >=20 > > Do we know how compatible other ISPs are with CHAP? I know at least one t= hat > > only supports CHAP and so we would break compatibility with them since it= is > > probably not very obvious. >=20 > I am afraid I did not get this. If the ISP supports CHAP only, everything is > fine, isn't it? >=20 > Of course, they are certainly ISPs which do not support CHAP at all. But si= nce > existing installations are not changes, this does not break running systems. >=20 > 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: "Y= es, > 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 user= s. 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: > >=20 > > a) it might break compatibility. pppd will always use CHAP if it is > > available > > already and fall back to PAP when necessary. >=20 > 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 challe= nge > > 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. >=20 > 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 witho= ut 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. > >=20 > > c) The Internet connection is a public thing. The user credentials are ea= sy > > to > > socially engineer. Even if the authentication would use CHAP this won't > > improve > > any security of the data being transferred after that. >=20 > True. But preventing against social engineering is out of the range of IPFi= re. > :-) Yes. Point is, that the login credentials are a public thing any ways. Some ISPs j= ust 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 >=20 > Best regards, > Peter M=C3=BCller > >=20 > > Best, > > -Michael > >=20 > > On Sun, 2017-11-19 at 14:47 +0100, Peter M=C3=BCller wrote: > > > Use CHAP as default setting for PPPoE dial-in connections. > > >=20 > > > Although CHAP does not provide strong transport security > > > at all, it is better than submitting credentials in plain text. > > >=20 > > > Enforcing CHAP prevents the system from silently falling > > > down to no encryption (MITM attack!). > > >=20 > > > Existing installations remain untouched. > > >=20 > > > Signed-off-by: Peter M=C3=BCller > > > --- > > > html/cgi-bin/pppsetup.cgi | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > >=20 > > > 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'} =3D 30; > > > $pppsettings{'TIMEOUT'} =3D 15; > > > $pppsettings{'MODULATION'} =3D 'AUTO'; > > > - $pppsettings{'AUTH'} =3D 'pap-or-chap'; > > > + $pppsettings{'AUTH'} =3D 'chap'; > > > $pppsettings{'DNS'} =3D 'Automatic'; > > > $pppsettings{'DEBUG'} =3D 'off'; > > > $pppsettings{'BACKUPPROFILE'} =3D $pppsettings{'PROFILE'}; =20 >=20 >=20 --===============2039509038034361757== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxvVUd6VUFDZ2tRZ0hudy8yK1EKQ1Fkd2NBLy9mTnFVVmhpS1Vz TmF0ZDFXZnhEM0x6eXdzWDFXTW1zeWRBRDBmelZENmtRUmRNT2hmOGhacEEwUQpRWlIveE9BT1Rs QTdIbVZhRGg4N3dtR1pQSExuSlhacFR5b3F2cFMxUUdLTXFBb1JzbngzTCs1UiswY2c4NUFOClk3 R05UL2tDa2xMc0NHSWsrNlM5Ymh0Qi91Ymg2WGh0Q25QSWlDM1Fyb09pUE1ycTFRQ0IzZ1BSdm9C eHdITDMKeDRkbDFLWk9yMk1DRVV3VGNZdTNEWDQ3NzlqbGdIamZaSTNrek1lMW9VVEtlQjZaVHZL QzRvSlpTRFJ4MTk3Rwp2YUpQN1BYU2hROVJaTXVYYVQydGVCVVNLaWNHS3BlbXBhS1B4eGNqNkx2 NEtyZmNvZWl1Z0U1OTBqN25uQVdNClM0OGpoS0dVVUZURmN1R3l4UXVqT1BqVWFKSjBnNGlqK0Ft bURnbGN2VVpkU0RBRUIyNnJnaU1RbmlUSnBiUzMKNlNsdHN4UG1DQ0thVDJwYWFZNjJCcFFibTh2 YWFLSmhYVFBWdWZmWjh3OUlicjN0TEhCb1dSMUE1VWRVclowVgp1WE5xbklkWXkvRXhXOGZTOGs5 bDZBMG1wWXJwLzRmanZqaWVwZUlUSTZTNFlBa1QyaVRSa2JmSW9PZU9Vd05wCk1USTFueDlaSXZB eTQrOGVjenRXN25rRU5pMTJJeW00czhvc0l5YUNnQXJRTkZuTkplOXNRbDl4UC9UUWpBbUIKNVpm MTdrSGJOM2kvd3o4YUlpalNlUThvNDlhZjlab285UnlKV1FLRkQ3MUp1dlBjSVgzWjdpbStRdkN0 ZXJTdwoxTWQzZTVCaDY2TVhadlA5djRHTnpuTVYwanB0ZURuQ2NSSTJxNVV4dE9yN2FRbVhBNGs9 Cj1vT2VPCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============2039509038034361757==--