Store database password

[Pat A]

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?

Thanks.

Pat

[Gordon Burditt]

>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.

You have to store <something> that will get you into the database.

Whatever that <something> is, it might as well be in plain text,
since by definition it gets you into the database, although you can
divide it up and scatter pieces of it around (which is security by
obscurity, which generally means not much security). If you further
encrypt, then the key to decrypt becomes part of the <something>
that HAS to be there to access the database.

Essentially, you're screwed, although some of the "security by
obscurity" techniques aren't 100% useless (having to calculate the
real password is a LITTLE harder than having it around in a file
somewhere).

Gordon L. Burditt

[dracolytch]

I have bad news. There are ways you could obfuscate what you're doing,
but ultimately you are sending the database a cleartext password.
That's what it requires. This means that anyone who can look at your DB
interaction code will be able to decipher what your application
password is.

That is why you limit access to your web db user to the localhost (So
someone from outside can't use that username/password, even if you tell
it to them). Have a separate username/password for external DB access.
I also recommend that you limit the permissions on your web DB user so
it can't alter/create/drop/etc if your application doesn't require that
it do so.

You could MD5 / base64 encode some text into a password, and use that
text as your application password. When they ask, say that it's a MD5
hashed value. It is cleartext, but at least it's basically random
cleartext. It's slightly dishonest, but they've asked you to do the
impossible.

If you limit your db interaction user to the localhost (since it's the
webserver on the localhost accessing the db), and have your
username/password in a file somewhere, then the only way to get at your
username/password is to get into your system at a level where they can
read your source. If they can do that, it's too late.

~D

[Justin Koivisto]

Pat A 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?

I went and purchased ionCube Encoder just for that reason. I didn't find
any other method that couldn't be cracked in less than a couple day's
time - by someone else of course. ;)

Of course, then there are some added benefits to using ionCube as well
that helped persuade my purchase. ;)

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Jason F.]

Justin Koivisto wrote:

Of course, then there are some added benefits to using ionCube as well
that helped persuade my purchase. ;)

Such as? By far the only reason people use ionCube is so that they can
get some vendor lockin by obfuscating the source code. That's nothing to
smile about.

[Justin Koivisto]

Jason F. wrote:

Justin Koivisto wrote:

Of course, then there are some added benefits to using ionCube as well
that helped persuade my purchase. ;)

Such as? By far the only reason people use ionCube is so that they can
get some vendor lockin by obfuscating the source code. That's nothing to
smile about.

obfuscating? No, it's actually encryption...

There are handy features with the Pro version GUI (I think they renamed
it to Cerberus now) for packaging and distributing. I've also found that
in many cases, there is a performance boost, and the fact that I prevent
unauthorized files from including the encoded files helps me ensure that
correct version of the files have been shipped with the product.

Then there are what you would call the "vendor-locking" features like
limit script to run on certain IP (or MAC) address, server name,
expiration date, etc. Except for the encoding of the source, I don't use
and of those anyway. The biggest reason for the purchase was the fact
that I could encrypt my database connection details to be used on a
shared server where I had no control of the environment.

The fact that competitors that use the same server couldn't get the
source was just a plus to help me sell it to my supervisors. So again, ;)

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Malcolm Dew-Jones]

Pat A (pw*******@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.

[CJ Llewellyn]

On Thu, 12 May 2005 13:01:37 -0700, Pat A 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.

The only way to avoid storing the password on the server is for the user
to supply it on each request he/she makes to the application.

You could use the database's own authentication system to regulate access.

Start by having a low priveledged user name & password that has read only
access to the tables used to generate public content.

Then for each operator of the system create users with higher levels of
access.

[Justin Koivisto]

Pat A 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?

OK, there is also another way to do this that I had mentioned in a few
groups a couple years back...

If the server is apache on *nix...

1. httpd.conf should be chown root.root, chmod 600

2. in the virtual host for your domain, use SetEnv to create variables
like SQL_HOST, SQL_PASS, SQL_USER, SQL_DB

3. in PHP, access these variables as $_SERVER['SQL_HOST'],
$_SERVER['SQL_PASS'], $_SERVER['SQL_USER'] and $_SERVER['SQL_DB']

Doing this ensures that only someone with root access can actually
see/edit the details in the file on the server. Putting the statements
in the VirtHost container ensures that only your domain requests have
those variables set to your values.

Of course, they would have to be stored in memory *somewhere*, so it's
always possible to get the details (just hard to do).

I don't know what other servers have these capabilities, but on IIS/PHP,
you can have different php.ini settings via registry edits, so you could
actually set up your database details through that. (Don't know if
unprivileged users could get registry values, but wouldn't surprise me.)

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Chung Leong]

You didn't mention what database software and what OS. For MS
SQLServer, you can use the credential of the account running the web
server to authenticate instead of username/password. The same can
probably be done in other software/OS.

[Jason F.]

Justin Koivisto wrote:

1. httpd.conf should be chown root.root, chmod 600

2. in the virtual host for your domain, use SetEnv to create variables
like SQL_HOST, SQL_PASS, SQL_USER, SQL_DB

3. in PHP, access these variables as $_SERVER['SQL_HOST'],
$_SERVER['SQL_PASS'], $_SERVER['SQL_USER'] and $_SERVER['SQL_DB']

Doing this ensures that only someone with root access can actually
see/edit the details in the file on the server. Putting the statements
in the VirtHost container ensures that only your domain requests have
those variables set to your values.

One forgotten print_r[$_SERVER] debug and you're screwed.

[R. Rajesh Jeba Anbiah]

Pat A 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.

<snip>

IMHO, as long as you aren't using shared hosts, no need to worry
about that. And as the rule, script has to use a low access db user and
has to be a cron job for taking DB back up.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Pat A]

I figured out a way to do it on Windows. I've written a C++ command
line app that uses the MS Crypto API and CryptProtectData to encrypt
the password. This uses the credentials of the logged on user as the
key. So, the user, by way of logging on to the site, decrypts the
password without even knowing.

It works great.