Passwords in scripts
 

I have a script to automatically log into a remote site and backup databases etc.

All works well but I'm uncomfortable having the password in plaintext. Is there any way to hide the passwords from prying eyes?

Many thanks
Tim

Log in using ssh with public/private key - no password required. See the ssh-copy-id command.

Or are you referring to database passwords in cleartext?

Any password really.

there's always a tradeoff between convenience and security.
you can't have both.

that said, it might be possible to have some sort of basic encryption or rather obfuscation on the password, so you don't have it inside the script (or some other file) in plain text.

my distros packet manager shows a few results when searching for "password encrypt" - i suggest you do the same.

or see here:
http://stackoverflow.com/questions/5...r-php-constant
(just the first search result)

I thought that might be the case.

The problem is that even though ssh doesn't require an embedded password (using RSA), it only works if the RSA key is unencrypted... If they are, then you have to supply a passphrase either directly, or through the user agent tool which retains that passphrase/unencrypted keys to supply to ssh (which is still better than embedding the password in a script).

The problem with database passwords is that there is no alternative. They have to be in cleartext when supplied to the database to establish the connection (one of the problems with web services is that the unencrypted password is in the web scripts, and I have not seen any alternatives either).

Feel stupid
 

I researched this very problem, and found only a few solutions. These are the only ones I adopted:
1. do my connections (At lease if they require passwords) from a well secured and locked down machine, so that no one but I have ACCESS to see anything that would give away the password. (As a system guy, this made sense but is obviously only as good as your isolation precautions).
2. Hard code the passwords into encrypted executables. (This only makes sense if you come form a programming background, I do)

And in both cases, use a secured channel for communications (VPN, ssl tunnel ala ssh, etc).
In the end, you cannot make it impossible to break password based security. Your objective is to make it so troublesome or expensive that no one will bother.

It seems stupid that OS and SYSTEM people have developed better answers, but the DATABASE people are still using 1980s solutions. (Says the guy who only USES databases, and has rarely developed DB software!)

The problem with databases is that no matter how you use them, applications are what connects. If if no human is involved (which is the majority of the case with batch processing), then the password MUST be provided in clear text.

Thanks for the information.
It's odd as I thought Linux was pretty much built with security in mind. I would have thought there would be some way to have a hash function or something. I guess for FTP the certs are a good solution.

Anyway, appreciate all the help.
Tim

Just for the record.
Linux is the kernel, and it is secure as the team and Linus T. can make it.
Your access is (mostly) controlled by applciations, generally GNU, and as secure as R. S. and that team can make them.

Databases are different teams, and they do not always communicate well with the first two.

When most people say "linux" they really mean the distribution or OS that blends the first two, and arguing about the real meaning is splitting hair (of which I have VERY few now) and a waste of time and talent.

Blaming Linux for database, shell, network, or application behavior is pointless unless you are willing to act to fix the problem.

The third, the database people, generally live off in their own little world. (Exceptions abound, natch.) Secure is nearly always second to "make it work" followed by "faster", because that is what their users demand of them!

All three groups are REALLY, REALLY smart people! None of them deserve disrespect. I would not have that job for the world and can only stand in awe.

That said, if you want a password-free way to securely access data in your database then you need to TELL them! Pick one or more of the database engines you would like to use, find those forums, and start asking about a solution to this problem. These guys LOVE a challenge! You may not like their solutions, but there WILL be solutions. That is pretty much how this all works.

If you do not ask, it may never happen.

Oh, it has been asked.

The problem is that no matter what you use... a password in cleartext (or its equivalent) always shows up. Use a dongle? still unencrypted password... no intelligence in the dongle, it will supply a key as long as it is asked appropriately. Want that request encrypted? then you have to have an unencrypted key entry to set the link up... and that becomes your unencrypted password.

Even with SSH - the authentication keys have to be unencrypted to be used...

All that happens is that the password is in a different location.

All solutions are wrong?
 

jpollard: suggest, then, an alternative.

The closest I've seen has been Kerberos. A time limited credential.

Unfortunately, that has exactly the same weaknesses as a password - other than the requirement to periodically renew the credential.

If the credential can be captured, the database is vulnerable until the credential is revoked or times out. On the plus side, the timeout period can be short. Though the shorter it is the more often the credential has to be renewed.

It also doesn't work well with things like web servers due to the need to renew the credential (which tends to make people create longer term credentials...)

There IS no good solution.

Only a variety of poor ones.

quoted for truth.
after having been linked here from a newer thread.

Nearest I can think is to store the passwords (in plain text) in a file on a folder that is readable only by the genuine user or group.

In the password script you might then write something like
pass=$(cat securefolder\securefile)

At least front end will not directly see the plain text password.

OK