On Tue, Jan 16, 2018 at 6:36 AM, ummeegge ummeegge@ipfire.org wrote:
...
Another point in here is IPFire uses currently the level 3 of --script- security for the RW " 3 -- Allow passwords to be passed to scripts via environmental variables (potentially unsafe)" which is important for some kinds of authentication methods but which has also been marked as unsafe and have also be again pointed out while the QuarkLabs and Cryptography Engineering LCC audit --> https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerA... its --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3" you can find there also OpenVPNs statements causing this topic.
AFAIK we don't use any of those authentication methods. Or are we?
Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...
Be careful of allowing users to be on their own if your goals are security objectives. The results usually leave a lot to be desired.
From NaCl's "Expert selection of default primitives"
(https://nacl.cr.yp.to/features.html):
Most programmers using cryptographic libraries are not expert cryptographic security evaluators. Often programmers pass the choice along to users—who usually have even less information about the security of cryptographic primitives. There is a long history of these programmers and users making poor choices of cryptographic primitives, such as MD5 and 512-bit RSA, years after cryptographers began issuing warnings about the security of those primitives.
It may be a better idea to support users if that is what they demand.
If you are drop dead opposed to the support, then make it hard for users to do it. Don't make it easy to do the insecure end-around. This is part of the "easy to use correctly, hard to use incorrectly" security design principal.
Sorry about the bikeshedding.
Jeff