Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

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 hardcoded in the script.

What are better ways to run this script without hardcoding/exposing the password?

share|improve this question
add comment

marked as duplicate by Gilles, Adnan, Luc, NULLZ, Rory Alsop May 29 '13 at 12:44

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
Does a key-pair really change things though? You still have a set of credentials stored on the filesystem. You have only really changed the size/type of the credentials. Unless of course you are doing something fancy with a hardware security device where the private key isn't on the filesystem. –  Zoredache May 17 '13 at 7:12
    
@Zoredache I've updated my answer. –  AbsoluteƵERØ May 17 '13 at 7:30
add comment

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 use the same script for several systems (with different configuration files)
  • you will be able to share the script with others (or show it to someone without compromising your credentials)
share|improve this answer
2  
Matteo - another benefit is you can centralize audit of the credentials file. –  Deer Hunter May 17 '13 at 5:44
add comment

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.

share|improve this answer
    
And then you occasionally commit the script into source control and voila! –  constantius May 17 '13 at 7:18
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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