Review and tighten access to .ovpn and .conf.dpapi

[rozmansi]

Check and determine least set of ACL required by tunnel config files. Maybe encrypt it with a securely stored key?

[ghost]

We also need to look at the OAuth access token that should be protected somehow.

The access token is only valid for 1 hour, so that limits its use. The refresh token can only be used once, so as soon as the legitimate client tries to use it refresh token (and the attacker already did before) the whole authorization is revoked. So perhaps it is not that important to secure the token(s)?

As far as "hardening" OAuth is concerned: an approach using a TLS client certificate to authenticate to the token endpoint could be implementend. Propbably only as part of #202 though.

[rozmansi]

We also need to look at the OAuth access token that should be protected somehow.

Access tokens and refresh tokens are protected with Windows built-in DPAPI user session key when stored on the disk. The function call sequence goes like this:

1. https://github.com/Amebis/eduOAuth/blob/master/eduOAuth/AccessToken.cs#L151 AccessToken.FromBase64String(string base64)
2. https://github.com/Amebis/eduOAuth/blob/master/eduOAuth/AccessToken.cs#L367 AccessToken.AccessToken(SerializationInfo info, StreamingContext context)
3. https://github.com/Amebis/eduOAuth/blob/master/eduOAuth/AccessToken.cs#L337 AccessToken.Unprotect(byte[] encryptedData)

This makes tokens from the user.config file useless on another computer and/or another user profile on the same computer when merely copied. However, an attacker can build own executable having DPAPI to decrypt the tokens if able to make the executable run as the attacked user. So, the token protection is only as good as users are aware not to run untrusted executables.

As far as "hardening" OAuth is concerned: an approach using a TLS client certificate to authenticate to the token endpoint could be implementend. Propbably only as part of https://github.com/Amebis/eduVPN/issues/202 though.

Implementation note: The client certificate private key should be saved in the user certificate store and marked as non-exportable. Edit: Which would require use of Windows built-in crypto for TLS meaning we're back to square one with TLS 1.3, happy-eyeballs and other future features we are pursuing with #202.

[jwijenbergh]

For eduvpn-common I'm implementing a method that allows you to customize the encryption method used to store the access/refresh tokens. So the windows client can still use DPAPI and Linux can use the keyring, e.g. the gnome or kde keyring or something else if available. As you said this does not protect against more sophisticated attacks, but I imagine that in this case it's easier for the attacker to steal your cookies and obtain tokens himself