Shell Programming and Scripting

I Apologies for that Neo, will keep that in mind, cheers.

Thanks,
R. Singh

Hey Ravinder,

Don't worry about it at all.

Most people make the same mistake, because your original reply was based on the "correct theory" which is not to store passwords in clear text.

Unfortunately, in practice, as mentioned, every one of the millions of WP and CMS sites on the web all have clear text DB passwords stored in config files.

If you don't have experience with deploying these CMS, you would not know that.

In defense of freely available CMS software, they must store DB passwords somewhere, so generally speaking it is a matter of standard unix / linux filesystem and file security.

You should do a risk analysis and determine the threats, risk and vulnerabilities and decide the best controls to use based on your risk profile.

If I read your post correctly, you are working on a linux box (which one?) or unix box (which one?) in a commercial application with multiple users with access on that server.

So, you need to look at the permissions, and so I assume the DB is not running as root (that is very unusual), so it is running as a user with certain privs.

You need to example DB privileges relative to the users on the system and come up with a strategy to mitigate risk.

Normally, users cannot read others users files if the permissions are set so others cannot read or access.

So, if your DB process can read the file with the clear text password, but others users cannot, then that is obviously one first step.

If you describe your system environment in more details and your view of the risks (in the case of compromise), then I can assist further.

There is a difference based on the risk, as I have mentioned, and you need a variety of controls (physical, logical [meaning technical] and administrative [meaning rules in this context]) when viewing IT security controls.

wordpress, wikipedia, et al don't encrypt their database passwords since there's not much point. They need the password every time. If it was encrypted, they'd just have to decrypt it, and if the program can do that without human input, so can an attacker.

I suppose it might just help to know what you are trying to connect to and using what tools.

As an example, if you are connecting to a local Oracle database instance then you can set up a user account with the phrase IDENTIFIED EXTERNALLY so that the DB trusts the OS user. Other options may be available.


Can you tell us what you actually need to create/obscure? It's all a bit crystal-ball-time at the moment.




Kind regards,
Robin

Just to add to this, and to emphasize what others have said:

When we store a user password in the DB, for example a web site DB, that password is the cryptographic hash of the password + a bit of salt. When a user logs in they normally type a plain text password and that password is sent in plaintext across the net, hopefully in a secure SSL channel. At the server side, the plain text password is retrieved by the server side logic and then the cryptographic hash + salt is compared to the same in the DB.

In some cases, the hash (more often than not an "md5()" hash) is stored locally on the client side the hash is sent as a cookie (or a $_POST or $_GET var), for example, so the plaintext password is not required (this is but one scenario).

However, on the server, we assume there is some standard file system security in place.

So, when an application needs to access the DB, normally the password is stored securely in a plain text configuration file. Likewise, we can store the hash instead of the password, but since the hash of the password and the password can both be used to gain access, most "day to day CMS" systems store the plaintext password in a secure file.

Some people hide this file is some obscure location on the server, like in a "hidden" dot file. This kind of security-by-obscurity is not very good, but some think it is better than nothing.

However, this is just a description of basic authentication.

Systems which have a higher risk use more complex (and expensive) methods for authentication.

As Robin mentioned, we need the details of the application and basic system architecture to properly advise; and as I have mentioned, we should know the risk profile of the system, to really help you.

Sorry for the late message....


Thanks for all the valuable inputs.


Here is the scenario:
I have a group of developers that write scripts on AIX 7.
I don't want everyone to hard code the database (IBM DB2) passwords in their shell script.
If I put the global configuration file and controlled with file system permissions, one can use

Code:

echo

statement to split that into a log.


I think the other way to achieve is, if I provide a database connect method in global file, then one can call the method when the script needs to connect to database. Still there will be security gaps, but may be a workaround.