Not storing passwords as plaintext is a good idea. However, storing them using an easily reversible encoding scheme doesn't actually improve security at all (with the possible exception of "shoulder surfing" scenarios). And if security is not an issue, why obfuscate the passwords at all?

If you just want to store the passwords in a separate file, you can pull them in using the < redirection operator.

To make the passwords slightly less readable, you could store them using base64 encoding:This is basically what you're doing in PowerShell.

Of course, you could use openssl to actually encrypt the passwords, but since you'd have to specify the decryption password in the script, that would be no real improvement over simple encoding.

If the file contains the hostnames or IP addresses of the servers, you could easily add the (encoded) passwords in a second column and use a combination of grep and cut to retrieve them.

1 members found this post helpful.

I never said I used the powershell script for ftp operations. I posted the powershell example to show how I authenticate while using powershell and a text file containing an encrypted password. My question was simple. Can I do with bash script, what I do with powershell. ie. have an encrypted password in a text file, and use it in a bash script to authenticate.

I understand what you are saying, and security is not really an issue in that specific environment. No one will try to hack these files to find out the password. In most cases if someone asks me I'll give it to them anyway. I just don't want files containing passwords accessible with a double-click. (or cat in this case).

I appreciate the code you posted. How would I read the passwordfile in my bash script?

VAR=$(base64 -d passwordfile)

Something like this I presume?

and then use $pass

you beat me to it. thanks

well theres your problem. has your company thought about upgrading to scp/sftp ? then you could just use public/private keys.

my company has a bunch of old mainframes which i ftp stuff from time to time and my heredocs have my username and password in clear text.

i dont feel guilty because in case of a breach i will just tell them if they really cared for security they wouldve upgraded to a more secure system years ago.i suspect its doing something slightly more sophisticated than circular shifting the password by 5 characters or so, e.g.:and then the closed-sourced binary will just undo the algorithm on-the-fly (security by obscurity) ?


also wouldnt rsync be the preferred method here ?

But then you don't qualify for the UUoC award.

(I believe the use of either redirection or cat and pipes can, in some cases, make a script more readable than if one uses a command's built-in ability to read a file. And in some cases there are subtle differences in how the command handles the data, gzip being example.)

1 members found this post helpful.

pass=$(cat password.txt | base64 -d)
will construct an additonal process and a pipe which is definitely slower and eats up more resources. (Obviously?) in this case it is not important at all, but in general this practice is not really recommended.

So basically

$ echo bubbaspassword | base64 | tee /dev/stderr | base64 -d

Or something like that. Swapping base64 for pgp or some other encryption standard. Not that it matters, having the encrypted password and the means to decrypt it kind of defeats the purpose. Outside of defeating some find scanning software looking for exact matches to the unencrypted string. Much like storing that data in program as hex or rot13 or elongated code to stitch together a string from single chars over several commands so it doesn't show up when using the string command. Except when looking at the running program in memory.

1 members found this post helpful.

You would write a program, using some language like Perl or PHP or what-have-you, that would ... say ... interact with a database to retrieve strings from them and to unmask them.

But it would be far easier to connect using "sftp" and to install digital certificates at both sides which would allow the connection to be made "securely, but password-prompt free." The script is run from a user which has all the necessary certificates in its .ssh directory, and that is running an SSH-agent. The remote host accepts the connection upon presentation of this appropriate, unique, certificate.

And I think that you should be doing the same thing with regard to your Windows connections, too! A password is never good-enough. Both operating-system environments support this.

A command like rsync -az --rsh=ssh ... would handle the entire synchronization process ... in both directions, if you like ... entirely on its own, establishing a secure (password-free, if you follow my suggestion) connection, determining what file changes needed to be made, and magically making them.

1 members found this post helpful.

yup, reminds me of this:
http://www.linuxquestions.org/questi...9/#post5527225