>><VirtualHost 123.123.123.123>>
>>ServerName www.example.com
>>DocumentRoot /home/example/htdocs
>>php_value decryptionkey "123456789"
>></VirtualHost>>
>>
>>encode your secret data using the decryptionkey 
>>before hand, and then decode it on the fly using
>>the environment variable present in only in your 
>>vhost.
>>
>>I'm hoping that no one outside of your vhost can
>>see the value of that variable. (does anyone know 
>>if you can pull environment variables from other 
>>vhosts or if PHP can read httpd.conf?)

> Alas, if you have access to be altering httpd.conf for the "key" you suggest
> in the first place, I could just put my database secrets there and be done
> with it.  Make sure only root (Apache) can read httpd.conf, and the problem
> is solved...

One could put just a db password in the vhost environment or 
could do something to decrypt code on the fly. 

Could we make this work in a shared environment if httpd.conf 
were not world readable and the vhost contained a $cypher, 
$cryptmode and a $decryptionkey variable, and files owned by
the webserver user were all read only? 

Then doing something like this to protect secret code:

eval(mcrypt_decrypt ( $cipher, $decryptionkey,
join("\n",file('mysecret.inc') , $cryptmode));

> I *suppose* as an administration issue, having an ISP that 
> sets one value one time for you in httpd.conf is easier than 
> making them edit httpd.conf all the time for you, but...
> I don't foresee a lot of ISP's embracing this "key" solution, 
> personally.

There are ways to reduce the admin overhead on stuff like this...
for example one could give every user an include file doing 
something like this in httpd.conf:

## begin Apache vhosts
include /home/user1/vhost.conf
include /home/user2/vhost.conf
include /home/user3/vhost.conf

There'd have to be some validation of what was acceptable within 
those files for sure... (perhaps parse the file and only allow 
certain settings)... 

I think if there were a list of recommending practices on how 
to secure shared hosting environments on php.net consumer 
pressure/competitve advantage would sway some ISP into doing 
a little configuration work to protect/keep their clients happy.

-GED



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to