|
|
Posted by Malcolm Dew-Jones on 05/13/05 03:15
Pat A (pwalessi1@gmail.com) wrote:
: We have a dilemma. We are storing our database password in an include
: file that resides outside of the web root. The password is in plain
: text. So, no one can get that password because it can't be served up
: by the web server. So far, so good.
: The customer wants all of our passwords encrypted. So, how do I go
: about securely encrypting that password? If I use mcrypt, I have to
: store a key and an IV somewhere...and if those are in clear text, I
: might as well just store the password in clear text. That is to say, I
: could encrypt the password with a given key and IV, and then hard code
: that key and IV into my app and put the encrypted password into the
: database. But, there's really no security in that.
: Has anyone else done anything like this?
-1-
Require the user running the script to provide the password. Not good for
the general public, but is fine for a person like an administrator, or an
employee accessing a company's internal web.
-2-
Some databases have other forms of login support. Bascially the database
allows a login from specific userids, and leaves it upto the OS to control
access. In this case the userid that runs the database scripts would be
allowed access with out a password. As long as a person can't access that
OS account except through your controlled interface then they can't access
the database (except the way you want them to).
-3-
Require the customer to manually start some part of the process whenever
the server is restarted. For example an operator interactively enters the
password at the console during the startup. The password can then be
stored in memory somehow.
Of course this only works for places that have 7/24 operator support, or
don't mind being down some of the time.
Of course even then, the password can potentially be extracted from
memory.
$0.04
--
This space not for rent.
Navigation:
[Reply to this message]
|