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'};
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.
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.
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.
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.
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'};
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@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'};
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@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'};
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'};
-
Michael Tremer -
Peter Müller