Protecting a password in Bash Script

DevilWAH

Hi,

What methods do people use to protect passwords in scripts.

For example I have a script to run some back up against outdated devices that support Telent (so not the best security a way).

so I have a cron job that runs a script to do this, but the script has a plain text password saved in it, that I want to hide.

I have seen things like

Encrypting Shell Scripts - The Community's Center for Security (SHC) to encrypt the scripts,

and suggestions of mcrypt

, or

gpg.

But I wanted to get some ideas of how people here mange this. I can use shared keys, and ideal I want to save it all on the one box (not pull in passwords at run time from somewhere else)

Any ides or pointers would be hlpfull.

Cheers

Aaron

ptilsen

One thing I've done on the Windows side that is still applicable is to basically store the credentials in plaintext, but in a secure location that will only be accessed by the system or service account and never get stored on the system. This doesn't totally solve the issue, but if done right it can mitigate the risk of storing and executing a script with plaintext credentials. However, I'm definitely interested in hearing how others manage this as I've never really had a great method for dealing with this on the Windows or Linux side.

jibbajabba

Had a look at this? (never used it myself - was just a google hit)

security - Hide/encrypt password in bash file to stop accidentally seeing it - Stack Overflow

onesaint

You could try something like this with GPG:
encryption - Using expect script for gpg - password decryption - does not work - Stack Overflow

Generally, I like to have the script prompt for a password then pass it as a variable as opposed to storing it.

DevilWAH

onesaint wrote: »

You could try something like this with GPG:
encryption - Using expect script for gpg - password decryption - does not work - Stack Overflow

Generally, I like to have the script prompt for a password then pass it as a variable as opposed to storing it.

I would prefer to pass the password as a variable, but the script needs to be run as a scheduled task, can a cron job securely store and pass authentication at run time?

onesaint

Cron will just execute the script. As far as I know there isn't anything extra cron can do for encryption or hiding a pass. You can edit the cron.allow (cron.deny) file to only allow a certain user to execute the script, but thats about it. You could try placing a hidden file someplace with the user/pass pair, but thats still a password file lurking about. Maybe try to do something like create a global variable with the pass via cron at a certain time, then have your other script nullify the variable. In the end though I think it might be better to use PKI.

For PKI, have a look here:
David McNett :: using ssh public key authentication
and implementation in IOS/unix:
http://www.m00nie.com/2010/12/password-less-ssh-login-using-pki-to-cisco-ios/

Other tricks would be shc which will compile and encrypt your entire script. Again, though the user/pass will be in a file albeit encrypted.
Paranoid Penguin - Limitations of shc, a Shell Encryption Utility | Linux Journal

DevilWAH

As I mentioned its using telnet so cant use PKI, and i know telnet still sends plain text but I am concerned about the password sitting on the server for any length of time.

I have decided to go with the shc or encrypted script but I don't like it, as if some one gets hold of the file they can if the want extract the details.

So my solution was to do the following

ScriptA

#!/bin/bash

user=""
pass=""

. ./scriptb

echo $user
echo $pass

ScriptB

#!/bin/bash

$user = "username"
$pass = "pass"

with ScriptB the only one encrypted, and also cleaned out between the jobs, and re populated via a 3rd party server just before the jobs are due to run.

What I think is needed in Linux is to allow file encryption to be tied to a user account, so only that account can read the file, even if some one manged to remove the file, they still need the user account to decrypte it. But for now I think the solution I have will do fine, and it means I can have a number or scripts and a single file with all the credentials that I can lock down and secure as best as possible.

powerfool

Why is it using TELNET? If you switch to SSH, you can just do a certificate. I know, I don't fully understand the situation, but I know of relatively few situations where TELNET would be an absolute requirement. In any environment with security compliance requirements, the use of TELNET would be a finding... and now you are talking about storing the password on a system...

That password is going to be visible in plaintext on your network when you authenticate.

Just to let you know, we found the network monitoring software package, SolarWinds Orion, stores SQL passwords in the clear in a text file. We have been working with SolarWinds to change this.

You need to step back and think how you can improve this situation. This is a challenge for you, if you choose to accept it. Have fun with it and surprise yourself.

DevilWAH

powerfool wrote: »

Why is it using TELNET? If you switch to SSH, you can just do a certificate. I know, I don't fully understand the situation, but I know of relatively few situations where TELNET would be an absolute requirement. In any environment with security compliance requirements, the use of TELNET would be a finding... and now you are talking about storing the password on a system...

That password is going to be visible in plaintext on your network when you authenticate.

Just to let you know, we found the network monitoring software package, SolarWinds Orion, stores SQL passwords in the clear in a text file. We have been working with SolarWinds to change this.

You need to step back and think how you can improve this situation. This is a challenge for you, if you choose to accept it. Have fun with it and surprise yourself.

Now if you read my first post you would have read the line

"outdated devices that support Telent (so not the best security a way)"

possible I should have places "only" in between the "that" and "support"

I work in science and support bespoke equipment is part of the job. Yes it would be nice for it to support ssh, but considering it would cost several 10's of thousands to replace that's not going to happen.

yes pass words will be visible in plain text, however the devices connect directly back to the core, and are in secure locations. So for some one to sniff the traffic while theoretically possible, they would have to get past physical security, dig up fiber and put a tap in it, or hack the switches and mirror ports.

If you look on a network your be surprised just how much stuff is in plain text, so for the few milliseconds it will be on the wire I am not to worried, if some one can grab it there, then them nicking this password is the least of my worries.

paul78

Just curious, since you are already using a clear text password, is there a reason why you cant protect the script by making it root accesible only. It sounds like security isnt a huge deal and you just need to prevent access from the casual curious user.

UnixGuy

paul78 wrote: »

Just curious, since you are already using a clear text password, is there a reason why you cant protect the script by making it root accesible only. It sounds like security isnt a huge deal and you just need to prevent access from the casual curious user.

^^ This.


If using TELNET is inevitable, they you have to mitigate the risk. One important thing is done right is that your network is protected from sniffers. The next step you can do as paul78 suggested is to use Access Control properly (i.e. only root user can read/write/execute that text file). I can't think of anything else you do...