<p>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.</p>

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

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

<p>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 <i>obscuring</i> 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</p>

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

<p>@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.</p>

<p>@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.</p>

[{'answer_id': 18992, 'author': 'Judge Maygarden', 'author_id': 1491, 'author_profile': 'https://Stackoverflow.com/users/1491', 'pm_score': 0, 'selected': False, 'text': '<p>Is public key authentication a valid alternative for you?</p>\n'}, {'answer_id': 19717, 'author': 'Neall', 'author_id': 619, 'author_profile': 'https://Stackoverflow.com/users/619', 'pm_score': 0, 'selected': False, 'text': "<p>As long as all three of these things are true, you're out of luck:</p>\n\n<ol>\n<li>Server needs web access</li>\n<li>Users need absolute control over server (root)</li>\n<li>You don't want users to have server's web access</li>\n</ol>\n\n<p>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.</p>\n\n<p>Anything else you try to do is just fooling yourself.</p>\n"}, {'answer_id': 20160, 'author': 'T Percival', 'author_id': 954, 'author_profile': 'https://Stackoverflow.com/users/954', 'pm_score': 2, 'selected': False, 'text': '<p>Prefer applications that integrate with <a href="http://live.gnome.org/GnomeKeyring" rel="nofollow noreferrer">Gnome Keyring</a>. Another possibility is to use an SSH tunnel to an external machine and run apps through that. Take a look at the <code>-D</code> option for creating a local SOCKS proxy interface, rather than single-serving <code>-L</code> forwards.</p>\n'}, {'answer_id': 20191, 'author': 'jj33', 'author_id': 430, 'author_profile': 'https://Stackoverflow.com/users/430', 'pm_score': 1, 'selected': False, 'text': '<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n'}, {'answer_id': 26896, 'author': 'Jason Day', 'author_id': 737, 'author_profile': 'https://Stackoverflow.com/users/737', 'pm_score': 2, 'selected': False, 'text': '<p>There are lots of ways to obscure a password: you could store the credentials in rot13 format, or BASE64, or use the same <a href="http://www.cvsnt.org/cvsclient/Password-scrambling.html" rel="nofollow noreferrer">password-scrambling algorithm</a> that CVS uses.  The real trick though is making your applications aware of the scrambling algorithm.</p>\n\n<p>For the environment variables in <code>~/.profile</code> you could store them encoded and then decode them before setting the variables, e.g.:</p>\n\n<pre><code>encodedcreds="sbbone:cnffjbeq"\ncreds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`\n</code></pre>\n\n<p>That will set <code>creds</code> to <code>foobar:password</code>, which you can then embed in <code>http_proxy</code> etc.</p>\n\n<p>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.</p>\n'}, {'answer_id': 84136, 'author': 'Gunstick', 'author_id': 15653, 'author_profile': 'https://Stackoverflow.com/users/15653', 'pm_score': 0, 'selected': False, 'text': "<p>we solved this problem by not asking for proxy passwords on rpm, apt or other similar updates (virus databases, windows stuff etc)\nThat's a small whitelist of known repositories to add to the proxy.</p>\n"}, {'answer_id': 4219546, 'author': 'Chris Stratton', 'author_id': 429063, 'author_profile': 'https://Stackoverflow.com/users/429063', 'pm_score': 0, 'selected': False, 'text': "<p>I suppose you could create a local proxy, point these tools through that, and then have the local proxy interactively ask the user for the external proxy password which it would then apply.  It could optionally remember this for a few minutes in obfuscated internal storage. </p>\n\n<p>An obvious attack vector would be for a privileged user to modify this local proxy to do something else with the entered password (as they could with anything else such as an email client that requests it or the windowing system itself), but at least you'd be safe from inadvertent viewing.</p>\n"}, {'answer_id': 14215844, 'author': 'lumpidu', 'author_id': 503024, 'author_profile': 'https://Stackoverflow.com/users/503024', 'pm_score': 3, 'selected': False, 'text': '<p>With the following approach you never have to save your proxy password in plain text. You just have to type in a password interactively as soon as you need http/https/ftp access:</p>\n\n<ul>\n<li>Use openssl to encrypt your plain text proxy password into a file, with e.g. AES256 encryption:</li>\n</ul>\n\n<blockquote>\n  <p>openssl enc -aes-256-cbc -in pw.txt -out pw.bin</p>\n</blockquote>\n\n<ul>\n<li>Use a (different) password for protecting the encoded file</li>\n<li>Remove plain text pw.txt</li>\n<li>Create an alias in e.g. ~/.alias to set your http_proxy/https_proxy/ftp_proxy environment variables (set appropriate values for $USER/proxy/$PORT)</li>\n</ul>\n\n<blockquote>\n  <p>alias myproxy=\'PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW@proxy:$PORT"; export http_proxy=$PROXY; export https_proxy=$PROXY; export ftp_proxy=$PROXY\'</p>\n</blockquote>\n\n<ul>\n<li>you should source this file into your normal shell environment (on some systems this is done automatically)</li>\n<li>type \'myproxy\' and enter your openssl password you used for encrypting the file</li>\n<li>done.</li>\n</ul>\n\n<p><strong>Note:</strong> the password is available (and readable) inside the users environment for the duration of the shell session. If you want to clean it from the environment after usage you can use another alias:</p>\n\n<blockquote>\n  <p>alias clearproxy=\'export http_proxy=; export https_proxy=; export\n  ftp_proxy=\'</p>\n</blockquote>\n'}, {'answer_id': 44286349, 'author': 'leon22', 'author_id': 384556, 'author_profile': 'https://Stackoverflow.com/users/384556', 'pm_score': 3, 'selected': False, 'text': '<p>I did a modified solution:</p>\n\n<p>edit <code>/etc/bash.bashrc</code> and add following lines:</p>\n\n<pre><code>alias myproxy=\'read -p "Username: " USER;read -s -p "Password: " PW\nPROXY="$USER:$PW@proxy.com:80";\nexport http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY\'\n</code></pre>\n\n<p>From next logon enter <code>myproxy</code> and input your user/password combination! Now work with <code>sudo -E</code></p>\n\n<blockquote>\n  <p>-E, --preserve-env\n               Indicates to the security policy that the user wishes to reserve their\n               existing environment variables.</p>\n</blockquote>\n\n<p>e.g. <code>sudo -E apt-get update</code></p>\n\n<p><strong>Remark:</strong> proxy settings only valid during shell session</p>\n'}]
['https://Stackoverflow.com/questions/18943', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/199/']