Typically in a large network a computer needs to operate behind an authenticated proxy - any connections to the outside world require a username/password which is often the password a user uses to log into email, workstation etc.

This means having to put the network password in the apt.conf file as well as typically the http_proxy, ftp_proxy and https_proxy environment variables defined in ~/.profile

I realise that with apt.conf that you could set chmod 600 (which it isn't by default on Ubuntu/Debian!) but on our system there are people who need root priveleges .

I also realise that it is technically impossible to secure a password from someone who has root access, however I was wondering if there was a way of obscuring the password to prevent accidental discovery. Windows operates with users as admins yet somehow stores network passwords (probably stored deep in the registry obscured in some way) so that in typical use you won't stumble across it in plain text

I only ask since the other day, I entirely by accident discovered somebody elses password in this way when comparing configuration files across systems.

@monjardin - Public key authentication is not an alternative on this network I'm afraid. Plus I doubt it is supported amongst the majority of commandline tools.

@Neall - I don't mind the other users having web access, they can use my credentials to access the web, I just don't want them to happen across my password in plain text.


Is public key authentication a valid alternative for you?

Judge Maygarden

As long as all three of these things are true, you're out of luck:

  1. Server needs web access
  2. Users need absolute control over server (root)
  3. You don't want users to have server's web access

If you can't remove #2 or #3, your only choice is to remove #1. Set up an internal server that hosts all the software updates. Keep that one locked down from your other users and don't allow other servers to have web access.

Anything else you try to do is just fooling yourself.

+2  A: 

Prefer applications that integrate with Gnome Keyring. Another possibility is to use an SSH tunnel to an external machine and run apps through that. Take a look at the -D option for creating a local SOCKS proxy interface, rather than single-serving -L forwards.

Ted Percival
+1  A: 

Unless the specific tools you are using allow an obfuscated format, or you can create some sort of workflow to go from obfuscated to plain on demand, you are probably out of luck.

One thing I've seen in cases like this is creating per-server, per-user, or per-server/per-user dedicated credentials that only have access to the proxy from a specific IP. It doesn't solve your core obfuscation problem but it mitigates the effects of someone seeing the password because it's worth so little.

Regarding the latter option, we came up with a "reverse crypt" password encoding at work that we use for stuff like this. It's only obfuscation because all the data needed to decode the pw is stored in the encoded string, but it prevents people from accidentally seeing passwords in plain text. So you might, for instance, store one of the above passwords in this format, and then write a wrapper for apt that builds apt.conf dynamically, calls the real apt, and at exit deletes apt.conf. You still end up with the pw in plaintext for a little while, but it minimizes the window.

+1  A: 

There are lots of ways to obscure a password: you could store the credentials in rot13 format, or BASE64, or use the same password-scrambling algorithm that CVS uses. The real trick though is making your applications aware of the scrambling algorithm.

For the environment variables in ~/.profile you could store them encoded and then decode them before setting the variables, e.g.:

creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`

That will set creds to foobar:password, which you can then embed in http_proxy etc.

I assume you know this, but it bears repeating: this doesn't add any security. It just protects against inadvertently seeing another user's password.

Jason Day

we solved this problem by not asking for proxy passwords on rpm, apt or other similar updates (virus databases, windows stuff etc) That's a small whitelist of known repositories to add to the proxy.

Unfortunately I don't have any say in the proxying policy on the network. I have had this same situation in both universities I have worked in.