[plug] [OT] Password security with shared web hosting

[Onno Benschop]

I'm sorry that I read your brevity as a "tone" and will remember that
for our future conversations :-)

Back to the business at hand:

In order for an application that runs as a process in whatever way on a
web-server to contact a database, some form of database authentication
is required. I'm pretty sure this is universally true, but I'm happy to
be corrected.

Your question appeared to me to hinge on the security of the database
credentials if the source-code was compromised. I think that this is a
case of: "How do I protect my house from burglars if my front-door is
compromised." - in other words, it isn't possible.

Let me elaborate before you jump down my neck :-)

The database credentials can come from three environments:
     1. The user visiting the web-site.
     2. The script that accesses the database.
     3. A "middle-ware" interface that talks to the database on behalf
        of the script.

I think we both agree that Environment #1 is completely undesirable for
many reasons, the least of which is the management of the accounts for
each visitor. (More on that below - which should also address your
question about Client's Users.)

Environment #3 only really works if you are not playing ISP, but running
your own setup for your own applications. The "middle-ware" would run on
a different host from the web-server and not be accessible to the
outside world. It adds one (phony in my opinion) layer of security in
that the administrative scripts that talk to the middle-ware would in
turn be secured by other means. However if your web-server is
compromised, there is no security at all anyway.

Environment #2 is the most common and workable solution as I see it. The
skill is in protecting the scripts from access by unauthorised users and
a method of mounted directories and chrooted environments was suggested.

More on Environment #1.

As I said, managing the accounts that have credentials to access the
database, eg. each User account, requires some process. If the number of
users is low, a Client could log-in with their credential - coming from
the database - and create a User account, thus having never stored a
(potentially compromisable) password anywhere but in the database. This
implementation becomes completely unworkable when the number of Users
grows. A script would need to exist that has the ability to create User
accounts, but in order for this script to access the database, it would
need access to it, thus a stored password. Thus the problem is in fact
the same as Environment #2 and my point about the different points of
authentication stand.

If you're still reading, another solution would be to put the password
file in a place that is only accessible via an authenticated script,
perhaps the md5 of the script is stored, ensuring that only authorised
scripts can access the file - presumably via some API - but really, IMHO
if you're that paranoid about it, why is it accessible to the outside
world at all?

At the end of the day, security is not an absolute thing, just a matter
of how much for which purpose.

Now you can jump down my neck and tell me where I dropped the ball :-)


Onno Benschop 

Connected via Optus B3 at S27°52'30" - E151°16'25" (Millmerran, QLD)
-- 
()/)/)()        ..ASCII for Onno.. 
|>>?            ..EBCDIC for Onno.. 
--- -. -. ---   ..Morse for Onno.. 

Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon
ITmaze - ABN: 56 178 057 063 - ph: 04 1219 8888 - onno at itmaze dot com dot au