| Mark Rafn 2005-02-24, 5:58 pm |
| Benz <benjose@hotmail.com> wrote:
>Looking for some good thoughts on how to handle database passwords or
>even Ux password in shell scripts ??
Like most security questions, it's more complicated than it appears at first.
The big question is "from whom are you keeping the password secret?". At the
least, split the threats into:
casual or motivated attacker with a limited account.
casual or motivated root user.
motivated attacker with no account.
motivated attacker with physical access (i.e. stolen hard drive).
Also, you must decide if you need to protect only the password, or if you need
to protect the DB connection, once made and/or the data sent to and from the
application. You probably should worry about modifications to the application
itself, even if the password can remain hidden from the user.
>Right now we use .uid file in the home dir to keep the passwd in it.
Ok, so this prevents other casual non-priveleged users of the box from
getting the password. The actual user of the script can get it trivially, as
can root. Motivated disallowed users can perhaps find a local exploit or
social engineering to get it.
>But not the secure way of doing it.
This idea is flawed. There is no "secure way" of doing anything. There are
degrees of security against various threats.
>Especially when we use database connections for Sybase or Oracle, somehow
>or the other the passwords are displayed in some env-setup-config
>files(used to initialize the app.) or its embedded in the shell scripts
>itself. So doing a ps -ef from some other place would display the same.
You'll have to fix the app to use another mechanism for this, if you care.
Most DB apps have an option to read auth information from a file or from the
terminal to prevent exactly this information leak.
Personally, I'd rather just set the policy of not sharing a machine that has
sensitive information. If nobody but the owner of the script (who is allowed
to see the password) has any access to the machine, who cares what "ps" shows.
This also plugs holes like users finding a local root exploit and reading
files or memory locations that have sensitive info.
>I was thinking in terms of using a encrypt and decrypt type of
>methodology to keep passwords hidden or any is other smarter ways to
>handle this??
Encrypt/decrypt just moves the problem one step away. Now you need a way to
store the key to decrypt the password. It DOES plug one hole, presuming the
user enters the decryption key when the script is run, which is that someone
could steal the disk and read the password from it.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
|