I want to store the passwords in a global file, so that all the users will not use them to login but a process should use it. One way is to keep the passwords in a .ini file and execute the file in the start of the script and use that variable.
But with this, one can echo the variable in the script and see the value.
How are you guys storing, let's say production database password, and use that in the script while writing the database connect statements.
Hello karumudi7,
It is NEVER EVER recommended to store passwords either in plain text or in encrypted format. Why don't you try to use some certificate kind of thing(not sure in your app case), perfect example if password-less SSH which requires public key copied at target server and while making ssh it makes sure that user is NOT being asked for password etc.
Again DO NOT save passwords in any form, it is NEVER recommended at all.
Note: after Neo' comment adding this, you could not avoid writing passwords always but still use them safely.
Thanks,
R. Singh
Yes, I understand and I use SSH keys for password-less connections.
But it is more like when you are interacting with other services like database etc.
Ravinder,
Many systems on the network require passwords to be stored in a flat file.
It's not always avoidable, so you can't say "NEVER NEVER DO THIS"... spoken much like someone who has not built a production application which uses clear text passwords.
Theory is not always the same in practice.
Normally, these kind of DB passwords are stored in plaintext in files which are hidden from users, so we must look at who has access to the system, the risk, the criticality of the application and other risk management factors.
This is correct. Many CMS programs like WordPress store the DB passwords in clear text in a flat configuration file.
Thank you Neo for correcting me, I have deleted my answer now, considering it was not adding any value add to post.
Thanks,
R. Singh
Ravinder,
Please do not delete "wrong answers or mistakes" which people have replied to.
Everyone makes mistakes.
However, deleting posts which two people have replied is not really correct and is a "bigger mistake", in my view.
Just accept that you learned something and moved on; but I do recommend caution when you have strong opinions based on theory that do not match practical 'the way things are'... we all make mistakes. That's what makes life fun and interesting,
Plus, others can learn for your mistake, so please see it as a way to help others learn, thanks!
The approach to manage risk in IT should be based on a risk analysis.
For example, a person running their own blog who has not much to lose if their DB password is compromised has a much different risk profile than a bank doing financial transactions.
Security controls come with "costs" and so the controls used should be appropriate to the risk profile of the system.
All WordPress blocks, Wikipedia Wikis and indeed most all CMS apps freely available on the network store DB password as clear text in config files which with various standard unix / linux file system permissions and controls.
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. :rolleyes:
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
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.
Okay, so it's DB2. I think that it is usual for all DB2 users to actually be OS users and you might just need to set up the trust there. You might need to use sudo to run the processes as the nominated OS user that can connect to the database and do the work.
Can you force that through? make sure your sudo rules only allow them to run a specific script as the trusted account that means they can only do what you want, not just a general "Connect me to the database and wheeeee....."
Also, do not allow them to get to the shell prompt as the trusted account else they can probably bypass any rules you want to define. Basically, don't trust them to do anything at all except a very controlled script.
If this is for end users, then you might need to set the sudo rules to use NOPASSWD to permit them without prompting for their own password all the time.
I hope that this helps,
Robin
Thanks Robin for sharing it. Sudo with nonpasswd is really good idea. To be honest I myself did 1 automation few backs only with using this and this facility is cool and safe too.
Thanks,
R. Singh