Shell Programming and Scripting

This is for personal, interactive password authentication. What is being asked for is neither personal not interactive.

If you can't trust a file you've done chmod 0400 on to not be read by anyone it wasn't supposed to, your system isn't trustworthy.

Other noninteractive methods like system-based auth suggested in this thread are also good. In an ideal world the best way is to completely avoid the password, replace it with something else that can't be imitated -- like a valid logon to some user at system...

Thank you that is a good suggestion/feature which i just came to know. Problem is not just Database it has other stuff as well Informatica Accounts, FTP accounts.

---------- Post updated at 12:19 PM ---------- Previous update was at 12:07 PM ----------

I have decided to encrypt the passwords strings using openssl utility

Code:

echo passstring | openssl enc -aes-128-cbc -a -salt -pass pass:wtf

Then i am going to put these encrypted passwords inside a file(.passwd) and encrypt the file with a password file (passfile).

Code:

openssl enc -aes-256-cbc -in .passwd -out .passwd.enc -pass file:passfile

And as suggested probably i should configure SUDO behaviour & change the scripts to directly read from decrypted file and then decrypt the password strings like below

Decrypt file:
Decrypt passwords:

Code:

cat "${BIN_DIR}"/.passwd | grep "^TGTREPOPASS" | awk -F "|" '{print $2}' | openssl enc -aes-128-cbc -a -d -salt -pass pass:wtf

May be i would consider changing the existing Oracle accounts to OS authentication as well. please opine if you feel so

Thank you all.

How will you retrieve them when you need to use them? Assuming that you have this written in a script, then hey-presto, anyone reading the script will know how to decrypt the passwords. I would recommend against this approach and that you should look to remove the need for passwords by using a method of trust that is already established.

If your users have individual accounts and you trust them to login securely (i.e. they don't share OS passwords, the passwords are complex enough etc.) then you should look to trust the OS user to open the connection. If you are worried that they may do something else, write a sudo rule and get it done by a central account in some way. Write the script which is access only to this central account and let the users do a:-

Code:

sudo su - account -c /path/to/private/script

Make sure that they don't have blanket access to the account, just the script you want them to get to execute. Don't let them even read the script.

At a certain point, you have to trust someone, after all you are trusted to do anything you choose as you have the root account available to you.




Robin

Arien:

Your "file:passfile" file is sitting around unencrypted, and so is the script which tells the computer what to do with it. This is 100% of everything an attacker needs to get it all.

If your robber can get the files, he can get the passwords, it's just that simple!

You have put your things in a vault, then handed him the key!

You have added a steel door beside your screen door instead of in front of it!

How many times must we tell you -- encryption does not work that way? I am not being mean, contrary, obtuse, picky, or stupid. We get asked this dozens of times a year, and it really doesn't.

There's a fundamental flaw in your logic. Have you heard of the problem of "security through obscurity"? This doesn't even have the obscurity -- every time you add a new layer of 'security' to your passwords, you inevitably give your attacker complete instructions and passwords to get around them! It's inevitable because you're forced to keep them around -- if they're not there, it won't work!

You asked for the "standard method". sudo and chmod are it. I am entirely serious. Ideally you'd want to avoid password files altogether, but IF password files cannot be avoided, that's the "standard" way. Frankly far more secure than any rube goldberg machine, unless your machine is untrustworthy in general.

And if your machine is so untrustworthy that you cannot trust 0400 files in a locked, passwordless account to be secure, you are in deeper trouble than we can fix.

If this requirement is being forced on you by management, I wish you the best of luck trying to explain.

I get it what you all are explaning me i may have to explain my client as well but I should have a approach first to deal this, my client/management is asking for encrypted passwords (currently only encoded) and all these accounts/passwords are stored in file (.passwd) and this file should be protected as well as currently it has (-r--r--r--) permissions and it is a security risk.

I can tweak the permissions but all the application shell scripts are owned by root (never seen before) as they don't want any one other than root to modify scripts, there is application functional account which executes the shell scripts (-rwxr-xr-x 1 root root) also decrypts the passwords in file(.passwd) as part of script.

I am trying to figure out the approach i should built using the inputs from this thread and make my client happy.

Thank you.

No approach is better than what you have.

I mean that entirely literally -- not a figure of speech. Your aes256-encrypted passwords aren't safer than your base64-encoded passwords, or even your plaintext ones. It is exactly as safe as you'd expect echo secret-password | encryption-program | decryption-program | application to be, for the exact same reason. That's not what encryption is for.

Thought so. Last time this came up it was someone who'd been asked to build a wholly-encrypted laptop -- which he'd been informed had to boot and run without typing in a password.

Consider that combination. What, exactly, is being protected from who? It's the exact same problem, just a lot more obvious.

Yes. That is bad. Reduce those permissions as much as possible, -r------- if you can get away with it. That it's owned by root isn't bad necessarily, but world-readable? Yikes! Are you saying you're not allowed to modify the application scripts, or that they all run as root?

If the scripts don't contain passwords, it's not too dangerous to read them.

That the scripts are owned by root does not prevent them from being run as 'passworduser' by sudo. Your client will be less than ecstatic to realize your sophisticated encryption has continued to decrypt even after the server has mysteriously left the building. Their expectations are simply unrealistic.

Cleaning up file permissions is a great start. Clamping down on who is allowed to use root for what is also a good idea, as is segregating the file somewhere it can't be used without sudo's help. File and user permissions are your primary job here, they will take the most work and do the most good.

Also explore what alternate schemes are available, like passwordless logins from very specific hosts or accounts, etc. This problem is why such things exist. It's almost impossible to keep plaintext passwords perfectly safe.