Store credentials in OS keyring?

[njfox]

Hey @mazen160,

I've noticed this project is catching a lot of flak on Reddit for storing the OpenVPN credentials in plaintext on disk. I know it's only accessible by root but I was wondering if the team had considered integrating protonvpn-cli with the OS keyring (e.g. gnome-keyring, kde-wallet, etc.) instead. This seems to be how some other Linux packages manage credential storage and it seems sensible enough to me. Do you have any thoughts on how feasible this would be? I believe Python can use gnome-keyring pretty easily for example but I'm not sure about bash.

[mazen160]

Hi @njfox!

You're 100% correct. I'm not sure how to develop this feature exactly. Here are the problems:

1. The password has to be written on disk at a point to be used by OpenVPN (maybe we can use a device to act as a file?)

2. We need to support a large variety (almost all) Linux distros. Also, to support macOS.

I haven't worked with OS keyrings before, but I believe it would be difficult to integrate it. I'm not sure.

Maybe we can have the issue open for community thoughts and feedback?

[xilopaint]

2. We need to support a large variety (almost all) Linux distros. Also, to support macOS.

Maybe I can add macOS support for such feature. I will look into it in the coming days.

[njfox]

This library looks simple and would support a wide range of platforms, although embedding Python within the pvpn bash script was called out as an anti-pattern in a Reddit thread awhile back (nevermind, it provides a command-line utility keyring that could be called from bash in pvpn). It has official Arch, Ubuntu, Fedora, and Debian packages as well so it would be easy to add as a dependency.

Here is an example using the CLI, which would be pretty easy to do from the main script:

$ keyring set dummyprogram dummyuser
Password for 'dummyuser' in 'dummyprogram': 
$ keyring get dummyprogram dummyuser
dummypassword
$ 

Here is the entry in seahorse, showing that the password was successfully added to the existing gnome-keyring:

Maybe we can fall back to the current setup if the user doesn't want to or can't install it? Note that I have not done extensive testing of this library--I'm just throwing out some ideas. There are probably other solutions that could work as well or better for this use-case.

[illambias]

@mazen160

This tool is a cli tool, it will probably not be used by someone that does not have an understanding of the terminal.

For this reason (and simplicity too) I would like to suggest the use of pass (https://www.passwordstore.org/) or gopass (https://www.gopass.pw/) to store the credentials. Gopass allows you to create a store only for protonVPN which would be useful to separate protonvpn credentials from another pass or gopass store used by the user.
This solution is available on every distribution (pass is older so packages are available for more distributions) and is a light dependency (Linux users using the terminal a lot don't necessary have a full desktop environment and probably don't want the heavy dependencies that come with gnome-keyring or kde-wallet). The creation of the pass/gopass store (as well as a dedicated gpg key to encrypt all that) could be done in the protonvpn-cli, everything could be removed at uninstallation.

MacOS is also supported by those two tools.

EDIT: All other important informations (plan, last server, etc) could also be stored in the pass/gopass store

I currently don't have the time to do a PR but I could try to implement that for the beginning of 2019.

[njfox]

This solution is available on every distribution (pass is older so packages are available for more distributions) and is a light dependency (Linux users using the terminal a lot don't necessary have a full desktop environment and probably don't want the heavy dependencies that come with gnome-keyring or kde-wallet)

The dependencies for gnome-keyring seem to be roughly the same weight as for pass (at least on Arch), but I think pass/gopass are interesting ideas I hadn't thought of. How much overhead would these add for the user? I think the purpose of storing the creds on disk in the first place is to prevent the user from having to enter their OpenVPN credentials every time, but if they have to unlock a keyring or GPG key everytime for pass/gopass then we might as well not store them at all IMO.

I'm just asking because I've never used either package, so I'm not sure what the flow would look like.

[mazen160]

Hi @njfox @illambias

These are really nice ideas!
I like pass, but I didn't had the chance to test it before. It's the first time to hear about gopass. Interesting option too.

as far as I understood, keyring implementation can be distro-oriented (not sure, maybe keyring python package overcome these issues), where using a password manager like pass would be better from compatibility perspective.

Another part is, almost all apps currently store config credentials on disk. filezilla, mailing clients, browsers, etc..
Most apps threat-model is to rely on user in securing this part on Linux.

There is another concern when using a password manager or keyring: We need to write the file on disk at some point and keeping it on the disk while OpenVPN is running. This unfortunately have us get back to point 1.

Maybe there is a way to overcome this OpenVPN issue?

[njfox]

We need to write the file on disk at some point and keeping it on the disk while OpenVPN is running

Do we? I thought the point of keyrings/password managers was to keep the file encrypted on disk and just keep it decrypted in memory once unlocked. I may be misunderstanding the question though since I haven't looked at the protonvpn-cli code in awhile. My understanding was that it only needs the credentials when the user first connects, which could be grabbed from pass.

[mazen160]

@njfox
The handling of credentials in automated/programmatic manner in OpenVPN is using --auth-user-pass.

If there is a need to retry connecting, such as connection was lost, recovering connection, etc..., then the file is grabbed by Openvpn internally.

Maybe there is a way to overcome this, but I haven't seen other ways to do so and no one posted a way to do the authenticated connection without --auth-user-pass.

[njfox]

Ahh I see--that makes sense. Would it be possible to grab the output from pass/gopass and pipe it into --auth-user-pass in place of a text file? Alternatively it might be possible to retrieve them and pipe them into the binary with echo "$creds" | openvpn .. and skip --auth-user-pass completely. Just brainstorming.

[ghost]

Hi all,

Very interesting discussion... I would also share with you some ideas...
I have not been able to test this so far, but we could perhaps avoid any password manager at all and overcome the --auth-user-path problem by using bare-metal gpg and some shell functionalities. So something like this could perhaps work:

• first we would encrypt and sign on-the-fly the credentials with a gpg key of the user:
  echo -e "<login>\n<password>" | gpg -e -s -r <gpg_id> > ~/.protonvpn_cli/protonvpn_openvpn_credentials.gpg
• Then we would use a "process substitution" and "sourcing" to retrieve the credentials without creating any unencrypted copy:
  . <(gpg -qd protonvpn_openvpn_credentials.gpg)

[mazen160]

Hi @Picea !

Nice idea!!

But the problem is,

1. if the connection requires restarting, fetching the auth-user-pass won't work as far as I recall. But I assume since the previous releases, we pvpn uses OpenVPN caching, so this should not be a problem

2. We need to have a notification message to let users know of a month before the update. Will figure a way (probably via fetching an API message).

3. We need to automatically generate and fetch a GPG key for users - We should not assume that users have a GPG profile.

Maybe a PR would be cool!