Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm making a shell script that reached out to a web service with basic auth. I don't want to have to put in my username and password every time the script runs, but I also don't want to have the combo in plain text inside the script. I know the username and password get base64 encoded before they're sent across the network. Is there any way I could encode it beforehand and include that in the shell script?

share|improve this question
up vote 1 down vote accepted


Well, technically you could pass the raw Authorization header using --header. But the usefulness of that would be exactly zero. Base64 is only an encoding used to avoid corruption of binary data, but it does not hide anything – it can be reversed in moments, such as by using the base64 command, by anyone reading your script.

In other words, even if you do this, the password will still be in plain text.

share|improve this answer
Thanks for clearing that up but, do you have any suggestions on how I could 1)not enter the pw every time and 2)not store it in plain text or base64? – Greg Guida Feb 15 '12 at 14:39
Read it from an external file, and keep that file on an encrypted filesystem. For example, curl has a --netrc option to read from ~/.netrc, or you could use the shell abilities to read from anywhere. (eCryptFS makes it very easy to set up an encrypted ~/Private/ directory.) Alternatively, if you use GNOME or KDE or Windows or Mac OS X, it's possible to use the "keyring" function in them. – grawity Feb 15 '12 at 14:51

You could have the script read the password from a file. You can ensure the script is run with an effective userid that gives it read access to that file and set permissions so that no one else does.

You may have to jump through some hoops to be able to use setuid, which would mean that users who can read and execute the script could not read the password file. Unix.stackexchange has a good answer on this subject. In your case, don't elevate effective UID to root, just use an ordinary ID created for this purpose only (e.g. script runs as wally, wally owns password.txt (r--------) wally has no special priviliges but those needed to write logs or output files to be shared with others)

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .