>> >Usernames and passwords should really be stored in a database, with the[color=blue][color=green][color=darkred]
>> >password encrypted. You do NOT want such information sitting around in a
>> >file that every Tom, Dick and Harry can read.[/color]
>>
>> Yes, the data is sitting around *ON THE SERVER*. That shouldn't
>> be a problem if you have your own server all to yourself, where all
>> the Dicks that can read the data should be your employees.
>>
>> Even if you are on shared web hosting, it's only a small percentage
>> of the world that can read those files (but that's BAD enough). If
>> you are on shared hosting, though, this is a BIG issue.
>>
>> I don't particularly like PHP's default session handling of sticking
>> everything in little files. I'd rather it put this stuff in a
>> database. And since PHP provides for session handlers, it's not
>> at all hard to do just that. Arrange for the session handlers to be
>> set in a file included by every page (if you've got access to php.ini
>> or Apache config files, there may be easier ways), and you shouldn't
>> have to touch any of the code that actually manipulates $_SESSION.
>>
>> If you are sharing a server with other customers of the web host,
>> you have to worry about the security of your database also. How
>> do you store the password so YOUR scripts can use it and some other
>> customer using the same server can't?
>>
>> You probably shouldn't be storing passwords in session data anyway.
>> $_SESSION is stored on the server and can't be faked by the browser.
>> So once you validate the password, simply recording that he
>> successfully logged in the session (and when) against your user
>> database is enough if you trust that session hijacking is difficult
>> enough to not be a problem.
>>
>> Gordon L. Burditt[/color]
>
>Read
>
>
http://shiflett.org/articles/security-corner-mar2004[/color]
This is an interesting hack, but your typical shared-host webhosting
customer does not have access to their own <Virtualhost> section
in httpd.conf, nor is it likely that an ISP will let that customer
put in an Include directive which may act as a denial-of-service
attack on the server.
Bugs in provisioning code that auto-generates <VirtualHost> directives
included by an Apache config file have been known to prevent the
web server from starting, due to such mistakes (yep, mine) such as
assuming the sales staff will never enter a domain name with an
embedded single quote into the database, or that MIS would not allow
such a name to get into the database when they said this was locked
out when they were asked. Similar problems could occur with syntax
errors in SetEnv directives in an include file. For that matter,
so would deleting the file. Note: another interesting denial-of-service
attack against Apache starting up on very, very old versions was
not paying your domain name renewal to Network Solutions. If it
dropped out of DNS and appeared in certain Apache directives, the
server wouldn't start.
[color=blue]
>Chris' article provides a great hack to hide database creditentials and
>talks about the problems with security and shared hosting. I'd gotten
>around the "server must be able to read the files" problem by coding
>stuff with passwords in protected CGI scripts and using CGIwrap
>
>
http://cgiwrap.sourceforge.net/
>
>but the URLs become really long.[/color]
This is interesting but I'm not sure I'd want to lose the advantages
of PHP as an Apache module. Chances are my hosting provider wouldn't
go for it either.
I keep database passwords in a PHP include file *OUTSIDE* the
document tree. This is my own server on my own property so shared
use isn't an issue. If PHP breaks (it's been known to happen briefly
while upgrading it and Apache, sometimes longer if the build didn't
work right), you can't get to the include file (although PHP files
are served as text files) and if PHP is working, the include file
is accessible but not exposed.
Gordon L. Burditt
security of sessions 
