I have some scripts on Ubuntu Linux machine that logs in to a database server to run some maintenance daily. To login to the database, I need a password and right now it is hard-coded in the script.
What are better ways to run this script without hard-coding/exposing the password?
As mentioned in other answers your credentials will be somewhere accessible to your script.
But I would put them is separate configuration file which will be read by your script.
You will have the following advantages:
You can create public/private key pairs and encrypt the password. This should obfuscate the password from casual passers by, as they would only have the public portion of the key known to them.
You should also protect the script using directory and file permissions.
Additionally, (depending on the database) you should be able to create a user account for the database that has back-up privileges only. This would prevent someone from creating tables, dumping tables, and replacing contents. You can limit access to this user to the times you would expect the backups to run.
Update
This post on Comodo actually explains the keys a little better. Since you're worried about someone gaining access to the original password that exists in the code, the attacker would have to listen for the private key from the user triggering the script (which could happen via SSH on a cron on a separate [virtual] machine). Obviously there would be no point if you were storing both keys on the same system unless of course you were storing the private key with higher privileges than the public key.
Both keys together = password
About the permissions, if someone has access to your system and it's this much of a concern for a password to be stored on the box in a "readable format" it sounds like there are deeper issues with the configuration of permissions on the box itself. Additionally if someone can sudo and beat your own privileges (like the host that runs the box), then the key hashing is really the only option to prevent the admin user from getting into the database.
Additionally you would need to disable the root account on the database since this would allow the attacker to read the database tables anyhow.
Considering the automated nature of the script, I don't think there is a better way of storing the password besides hardcoding it.
My recommendation would be locking the script down with proper unix filesystem permissions. Making the script -rwx------ and setting the owner and group to appropriate values will go a long way towards securing the password.
Of course, have proper logging measures in place to detect if the script has been compromised. If it has, change the password on the database server immediately.
I like @absolute's answer about encrypting the creds with a key pair, I will also add that for Windows based solutions, I've just used C# instead of a powershell script at times; since they're both .NET based I can just compile my solution and toss the creds in there.
So, perhaps you can create a compiled executable that calls the script and passes the credentials as a parameter, or even an encrypted copy of the credentials as a parameter that your script can decrypt.
Yes, I'm aware that the creds can still be plucked from the exe in certain circumstances, but this is specifically for the OPs situation of avoiding clear text creds.
Perhaps you are asking the wrong question. While it is right to be concerned about scripts with hard coded authentication credentials, the real question is how to manage authentication credentials used by automated scripts and more importantly, what are the highest threats or risks associated with the system. Different systems have different risks. You need to understand the risks most relevant to your situation to assess what actions are most suitable. In general
Don't hard coded authentication credentials. Put them in a separate file/location and have your script use the info. This has the advantage of making it easier to change your passwords as you don't need to edit your sources and you can have multiple scripts use the same source, allowing you to change passwords in just one place.
Get to understand permissions, uses and groups. Use the facilities available to restrict access.
Use the additional hardening features of your OS. For example, Linux uses SELinux or AppArmor (I think ubuntu is based on apparmor). Define appropriate policies to restrict access to only what is absolutely necessary.
Understand and use the tools available - ssh, sudo, chroot etc.
Knowing and understanding where your threats are will determine which techniques and facilities are best suited and whether the default facilities are enough or whether you need to turn things up a notch and install additional precautions. don't overlook the importance of auditing and log analysis. It is one thing to put protection in place. It is another to know when your protection has failed and you have been compromised. It may be bad to have your system compromised, but it is far worse for it to be compromised and not know it.
If you're using ssh to log in to the database server, you can set up the ~/.ssh/authorized_keys on the database server to include the ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub file on your ubuntu system. The you will be able to log in without passwords.
If you don't have a file in ~/.ssh/id_dsa.pub look up how to create one with ssh-keygen
