Question on password visibilty?

[Phil Coen]

I have been learning PHP on my own time and have an Apache server on my
network at home. Obviously security is not a problem on this setup.

But as I begin to think about actually using code on a publicly addressably
server someday, the examples in my books seem to be wide open to the world.

Most use an HTML form that calls a separate php program. Most of the
passwords are either hard coded in that php module or are in a file
accessable by that module.

Heck, anybody can download the php script and look at the passwords. Or,
use it to see what file it is pointing to.

Am I missing something here?

Where should the logon security for the web site actually be?

Thanks anybody
Phil

[Geoff Muldoon]

Phil Coen says...

Most use an HTML form that calls a separate php program. Most of the
passwords are either hard coded in that php module or are in a file
accessable by that module.

Heck, anybody can download the php script and look at the passwords. Or,
use it to see what file it is pointing to.

Phil,

The PHP include() function, unlike the HTML include, can reference files
which are outside the Apache docroot.

If you *have* to hard-code passwords somewhere, at least put them in a
file outside the Apache docroot and use a PHP include() call to reference
them in any PHP scripts which are within the scope of the Apache docroot.

Geoff M

[Gordon Burditt]

>I have been learning PHP on my own time and have an Apache server on my

network at home. Obviously security is not a problem on this setup.
If it is accessable from the Internet, which it probably is if it
has a public IP, security IS an issue. Even if it's only on a
dialup line. Please don't run yet another infected zombie that can
be instructed to attack other systems.
But as I begin to think about actually using code on a publicly addressably
server someday, the examples in my books seem to be wide open to the world.

Most use an HTML form that calls a separate php program. Most of the
passwords are either hard coded in that php module or are in a file
accessable by that module.
If PHP is set up properly, Apache will *NOT* serve the text of a
PHP page, it will serve the OUTPUT of that page. Test it yourself
with a browser or telnet directly to port 80 of your Apache server.

Should you ever manage to break PHP, which I note happens briefly
during upgrades if I don't shut off Apache during the upgrade, it
could serve the text, which is a problem.

My solution (hardly original) is to put the passwords in an include
file *OUTSIDE* the document root. It might look like:

<?php
$mysql_server = 'mysql.mydomain .com';
$mysql_user = 'me';
$mysql_password = 'drowssap';
$mysql_db = 'weasels';
?>

and it might reside in /usr/local/share/php as "weasels.in c". You
use these variables as arguments to mysql_connect() or mysql_pconnect( )
and mysql_select_db (). Another advantage of this is that you can
change which database you are using by changing ONLY the include file.

Also, give the user 'me' minimal privileges that it needs to do its
job. This might be SELECT only, or it might be SELECT, UPDATE,
INSERT, DELETE on one database only. It shouldn't be able to alter
the schema. Many hosts for web/db setups will allow you at least
two MySQL logins, one for admin, the other for web use on the
same database.

If PHP is broken, Apache won't access the include file since it's
outside the document root. If PHP is not broken, you get the output
of the page, not the code. So, either way, you don't get the passwords.

Also, your MySQL permission setup should allow user 'me' to access
the database from only a small number of IP addresses (your web
site, and the site you do maintenance from, both of which might be
'localhost' only). That way, in order to *USE* the password if
they manage to steal it, they have to be able to write scripts onto
your web server and run them.
Heck, anybody can download the php script and look at the passwords. Or,
use it to see what file it is pointing to.

Am I missing something here?

No, anybody CANNOT download the php script, assuming that Apache
recognizes it as a script to be run with PHP.

Note that my suggestion does not help you in defending your site
against other customers (potentially competitors or scammers wanting
to steal credit card numbers) on a hosted site using the same server.

Gordon L. Burditt

[Phil Coen]

>

The PHP include() function, unlike the HTML include, can reference files
which are outside the Apache docroot.

If you *have* to hard-code passwords somewhere, at least put them in a
file outside the Apache docroot and use a PHP include() call to reference
them in any PHP scripts which are within the scope of the Apache docroot.

Thanks, Geoff. That got me a keyword to find in my php books.

Phil

[Phil Coen]

Thanks Gordon

If it is accessable from the Internet, which it probably is if it
has a public IP, security IS an issue. Even if it's only on a
dialup line. Please don't run yet another infected zombie that can
be instructed to attack other systems.
I hate zombies too.

No. The Debian/Apache server is only on my home network and is not set up
to see the Internet. I would actually be putting any real code on the
school admin server and it uses MS IIS which I don't know anything about
and don't want to know anything about. Especially since we have to
maintain a suicide watch over the poor folks whose job it is to maintain
it. I wish I could convince the powers that be to plop in a Linux server.

If PHP is set up properly, Apache will *NOT* serve the text of a
PHP page, it will serve the OUTPUT of that page. Test it yourself
with a browser or telnet directly to port 80 of your Apache server.
No, anybody CANNOT download the php script, assuming that Apache
recognizes it as a script to be run with PHP.

You are right. I can see the HTML stuff in my modules, but so far haven't
been able to download or see the php script as an ordinary user. So I was
under the wrong impression about that. Good. Well, I just started PHP a
week ago and am still in the thrashing around mode - barely beyond the
"Hello World" point.

I have written quite a few web pages over the years, all hobby type, and
never worried about security because I WANTED everyone to be able to see
everything. It was the hosters problem to keep people from trashing it or
whatever. But now as I begin to think about sites that are ONLY for
authorised users, all kinds of problems arise. Like realising that with
all the HTML sites that I have made before which were nothing but multiple
pages linked to each other, anybody could "deep link" to any one of them
without going through the index.html even it it had a login.

All of my PHP books are just for learning the language. Very little about
actual security in them. I am going to have to pick up a book that
discusses the layout of a real web server.

Thanks again
Phil

[Colin McKinnon]

Phil Coen wrote:

I have been learning PHP on my own time and have an Apache server on my
network at home. Obviously security is not a problem on this setup.

You think?
But as I begin to think about actually using code on a publicly
addressably server someday, the examples in my books seem to be wide open
to the world.

Most use an HTML form that calls a separate php program. Most of the
passwords are either hard coded in that php module or are in a file
accessable by that module.

Heck, anybody can download the php script and look at the passwords. Or,
use it to see what file it is pointing to.

Are we talking about passwords used by your PHP scripts to authenticate
against some other service (like MySQL) or to authenticate web users?

The former (which the previous 2 responders seem to be addressing) will
require to be stored in an unencrypted form (as someone else said - if your
webserver is setup correctly, they should not be visible). However the
latter (which you seem to be talking about) should never require an
encrypted password. Really, the stored token should be kept in a
non-reversible hash.

Unix authentication systems are well documented. Originally these used crypt
to hash the password, but more recently 3DES or MD5. Where you keep the
data is up to you - but even a 100% secure hash will not protect your
system against brute force attacks (particularly if the black hat can copy
the password file to his/her own machine and recreate the algorithm).

Of course you also need to think about how to secure the passing of
information to/from the browser. SSL is the obvious choice but introduces
of its own.
Where should the logon security for the web site actually be?

Kinda depends...

C.

[Ryan]

Phil,
Although I see many answers to your questions there is another VERY
important issue that has not been addressed. When you move your website
to a host will it be dedicated or shared?

* If it is dedicated then keeping your user/pass outside the webroot
directory will secure the file from being displayed over the internet
in the event apache breaks or a configuration has been mistakenly
changed.

* If it will be on a shared server then you must make sure you host has
configured the server correctly for security. Being on a shared host
means that there will be other accounts that will be able to login to
the server. If PHP is installed as a cgi and apache is using suexec
then all your PHP files will execute are your user name. PHP files can
have permissions that only your user can read them. This means your
files are secure.

* If PHP is installed as an apache module (most hosts do) then your php
files, including the file where your user/pass is in, must be readable
by apache. So they must be world readable. Without getting to indepth
and confusing you, the following must be observered.

1) All users accounts on the shared server must be jailed. This means
that a user is trapped inside their home directory when logged in (ssh,
telnet, ftp) which restricts them from reading files outside their
directory.

2) PHP's safe_mode must be on. This restricts a users scripts (which
are executing as apache) from reading files that it has permission to
if they are not readable by that user account.

I am a consulted and have worked on more then one project where it was
possible to retrieve other user/pass crediantials on a shared server.
Make sure your server is secure.

Phil Coen wrote:

I have been learning PHP on my own time and have an Apache server on my
network at home. Obviously security is not a problem on this setup.

But as I begin to think about actually using code on a publicly addressably
server someday, the examples in my books seem to be wide open to the world.

Most use an HTML form that calls a separate php program. Most of the
passwords are either hard coded in that php module or are in a file
accessable by that module.

Heck, anybody can download the php script and look at the passwords. Or,
use it to see what file it is pointing to.

Am I missing something here?

Where should the logon security for the web site actually be?

Thanks anybody
Phil