I have this file I use to set my username and password before exporting the value.

echo -n "User:";
read user
echo -n "Password:";
read -s password

export http_proxy=http://$user:$password@$domain:$portnum

if curl -silent http://www.google.com | grep authentication_failed;
        echo NO CONNECT
        unset http_proxy
        echo OK

in history, printenv, and export -p I'm able to see the value that I have set

furthermore, I'd like an encrypted form of my password inside $password, versus that value containing my password verbatim.

I'm familiar with using openssh to salt passwords, or printing hash using perl's crypt(), but for my purpose, I cannot see it's usage? any tips will be appreciated?

  • crypt is a one way function known as a hash. If you hash your password that you will be unable to retrieve the plaintext form. This is so that you can verify someone's login with storing their password in plaintext. It will not help you in this situation. You need to look at different forms of encryption such as RSA which being a two function which will let you retrieve the data.
    – Jacob
    Apr 2, 2014 at 18:55
  • What exactly are you trying to do here? Most applications that use http_proxy do not support any form of encryption of the credentials, if that is what you are asking. So you could certainly encrypt it, but nothing would be able to use it.
    – Zoredache
    Apr 2, 2014 at 20:47
  • There's not any need to encrypt the contents of an environment variable. The reason you can see them is that your user account has the same privileges. Try logging into a different account. You won't be able to see them in /proc/PID/environ. But you should make sure that the permissions on your script are restrictive, such as 0700, so that others aren't able to read its contents. Apr 3, 2014 at 1:46

3 Answers 3


I am unable to reproduce the issue you mentioned with password showing up in the output from the history command.

The password showing up in the output from printenv and export -p is working as intended. Those commands display the environment variables, and that's where you put the http_proxy string.

The environment variables are automatically inherited by child processes, but not by any other processes. I don't see why you think that is a major concern, as it is only visible to processes within the same security domain.

But you could stop putting it in an environment variable and instead use normal shell variables. Then it would not be inherited by child processes. Since you probably want curl to have access to the environment variable, then you could pass the environment variable to just that one command and not all the other commands.

echo -n "User:";
read user
echo -n "Password:";
read -s password


if http_proxy="$proxy" curl -silent http://www.google.com | grep authentication_failed;
    echo NO CONNECT
    echo OK

If you are passing sensitive information around and use it regularly you are probably best encrypting it using openssl

Putting something like

#create key as follows - will prompt for password
#echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64

Into your .bashrc will give you an encrypted environment variable that you can access where ever you need a secret, and you will be prompted for you passphrase/password that you used when creating the environment variable.

In the example above it is 'secret'

You access it is a command as follows

`echo $MY_SECRET|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2 `


xfreerpd /parameters.... /p:`echo $MY_SECRET|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2` 

For your query where you are creating an environment variable with your password built into the environment variable

You can create the variable as follows

password_encrypted=`echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64`

Then use it as follows

export http_proxy=http://$user:`echo $password_encrypted|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2 `@$domain:$portnum

The base64 part is so that you can set the variable


And not have your secret stuck in the command history etc etc.

When you generate the secret sometimes the base64 output will have multiple lines so you need to take the line breaks out for your variable.

echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

#take the above line break out 

openssh will prompt you for a password to encrypt and decrypt each time, you can supply one as part of the command, but then you are just hiding things from the history etc. Have a look at https://www.tecmint.com/generate-encrypt-decrypt-random-passwords-in-linux/ for some info on using openssh for this. https://www.serverlab.ca/tutorials/linux/administration-linux/how-to-base64-encode-and-decode-from-command-line/ for base64 and https://stackoverflow.com/questions/16072351/how-to-assign-an-output-to-a-shellscript-variable for different options on command substitution I have used back-tick ` above

PS Adding a function like

 echo -n "$1"|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2

To your bashrc gives you quick access to the secret if you need it


You should rather store the paasword in a secure file only readable by the current user.

Then pipe in that file content or use the mechanisms provided by your target app.

imho curl provides such options itselv.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.