Plaintext Password In Client Profile

[5r8Ucy4JuO 1]

Dear AirVPN staff

 

First of all, thank you very much for offering such a great service. So far, everything has been working without problems. The Eddie client is taking care of the concerns I had while using VPN (speed, failover, leaks).

 

I have however come across one thing that I am not a big fan of: The client is saving the login details without any regards to security inside the profile (AirVPN.xml). The file itself is readable by every user on the operating system.

 

There are better ways to handle the credential storage: OS X Keychain or the Data Protection API on Windows. This way, other processes or users would not have access to the AirVPN login credentials. I could at least fiddle with the file permissions myself to make the profile readable only by my user, but that is hardly optimal and should be handled by the client and not manually by the user.

 

Maybe there is a good reason that you chose to do it the way it is done now but I thought it would be important to address this.

 

Thank you very much in advance for your feedback.

[Staff 9751]

 

Dear AirVPN staff

 

First of all, thank you very much for offering such a great service. So far, everything has been working without problems. The Eddie client is taking care of the concerns I had while using VPN (speed, failover, leaks).

 

I have however come across one thing that I am not a big fan of: The client is saving the login details without any regards to security inside the profile (AirVPN.xml). The file itself is readable by every user on the operating system.

 

There are better ways to handle the credential storage: OS X Keychain or the Data Protection API on Windows. This way, other processes or users would not have access to the AirVPN login credentials. I could at least fiddle with the file permissions myself to make the profile readable only by my user, but that is hardly optimal and should be handled by the client and not manually by the user.

 

Maybe there is a good reason that you chose to do it the way it is done now but I thought it would be important to address this.

 

Thank you very much in advance for your feedback.

 

Hello!

 

Thank you for your great feedback!

 

Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie.

EDIT: the AirVPN.xml file although belonging to root:root is actually readable by every user, you're right. This needs to be fixed.

 

You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie.

 

Kind regards

[5r8Ucy4JuO 1]

Hello!

 

Thank you for your great feedback!

 

Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie. You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie.

 

Kind regards

 

Thank you very much for your quick reply.

 

Unfortunately, I have an unattended client and I do need to save the login details since at times nobody is around during startup.

 

Are there any plans to implement this or have there not been enough requests? At the very least, Eddie could set more restrictive file permissions on the profile automatically, that would be fairly simple, although I would prefer the more secure way of using the specific OS APIs to handle this.

[Staff 9751]

 

Hello!

 

Thank you for your great feedback!

 

Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie. You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie.

 

Kind regards

 

Thank you very much for your quick reply.

 

Unfortunately, I have an unattended client and I do need to save the login details since at times nobody is around during startup.

 

Are there any plans to implement this or have there not been enough requests? At the very least, Eddie could set more restrictive file permissions on the profile automatically, that would be fairly simple, although I would prefer the more secure way of using the specific OS APIs to handle this.

 

 

Hello!

 

No requests at all but this the correct way hands down, you're right.

 

Kind regards

[5r8Ucy4JuO 1]

 

 

Hello!

 

Thank you for your great feedback!

 

Yes, just like browsers if you don't use a master password to encrypt all other passwords. This option is not currently available in Eddie. You might like to not tick "Remember" in the login window: in this way the client will not store username and password and you can enter them anytime you run Eddie.

 

Kind regards

 

Thank you very much for your quick reply.

 

Unfortunately, I have an unattended client and I do need to save the login details since at times nobody is around during startup.

 

Are there any plans to implement this or have there not been enough requests? At the very least, Eddie could set more restrictive file permissions on the profile automatically, that would be fairly simple, although I would prefer the more secure way of using the specific OS APIs to handle this.

 

 

Hello!

 

No requests at all but this the correct way hands down, you're right.

 

Kind regards

 

 

Surprising that nobody has said anything about this

 

Thank you again for your feedback.

 

Kind regards

[zhang888 1065]

Just a small security related comment...

It doesn't really matter, in terms of security, whether the client config files are readable by anyone or not.

 

The Eddie client, just like any others (Viscosity, Tunnelblick) must have root permissions in order to start,

which makes any attacker capable to access the secure storage APIs OSX provides in order to read the

login/password from there.

There is a great description of those TOCTOU vulnerabilities here, a link which I posted some time ago:

http://blog.zx2c4.com/791

 

To address this issue globally, a different password should be used for the Eddie client rather than the

single-sign-on password for the AirVPN login system. That can be a client certificate, a hashed version

of the password or anything else.

Anything that would make the stored version of it unusable for the AirVPN site login.

Of couse it comes with a slight usability tradeoff, but this is the only -secure- way of implementing this.

Corporate VPNs never store the client login after the first installation, they generate a PKCS#12 cert and

store it afterwards, both on OSX and Linux.

[5r8Ucy4JuO 1]

Just a small security related comment...

It doesn't really matter, in terms of security, whether the client config files are readable by anyone or not.

 

The Eddie client, just like any others (Viscosity, Tunnelblick) must have root permissions in order to start,

which makes any attacker capable to access the secure storage APIs OSX provides in order to read the

login/password from there.

There is a great description of those TOCTOU vulnerabilities here, a link which I posted some time ago:

http://blog.zx2c4.com/791

 

To address this issue globally, a different password should be used for the Eddie client rather than the

single-sign-on password for the AirVPN login system. That can be a client certificate, a hashed version

of the password or anything else.

Anything that would make the stored version of it unusable for the AirVPN site login.

Of couse it comes with a slight usability tradeoff, but this is the only -secure- way of implementing this.

Corporate VPNs never store the client login after the first installation, they generate a PKCS#12 cert and

store it afterwards, both on OSX and Linux.

 

As far as I know, the concerns you mention are only a problem if:

1. A process which runs as root has a vulnerability which can be exploited to do arbitrary stuff

2. The OS X Keychain is unlocked

 

However, I do agree with you that using a different password for Eddie would be better than storing the single sign-on password anywhere, no matter how secure the storage is. But using secure storage APIs of the operating systems would still be much better than storing a plaintext password in a world readable file.