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

[Onno Benschop]

While I do have a thick skin, I was a little taken aback at the tone of
your response. I was genuinely attempting to assist you and feel that my
reply was thrown back in my face...

Your initial request read to me like this:
        I'm needing to setup some hosting services for an ISP like
        service but I'm concerned about security of the database,
        specifically, how do I protect the database against rogue
        scripts. Most solutions seem to require password files
        somewhere, but they seem to be accessible by other clients with
        legitimate access to the same service.

If that is not what you meant, then I misunderstand and perhaps I need
more guidance as to your actual question.

Note, Client means, person who has an ISP account who writes/installs
scripts that talk to the database. Users are people who browse to the
resulting web-site.

On Thu, 2004-08-26 at 09:35, James Devenish wrote:
> Hello,
> 
> In message <1093475029.3559.10.camel at latte.internal.itmaze.com.au>
> on Thu, Aug 26, 2004 at 09:03:49AM +1000, Onno Benschop wrote:
> > On Wed, 2004-08-25 at 23:20, James Devenish wrote:
> > >  - Using a dedicated web host, thereby having no "untrustd" sites on the
> > >    same host.
> > This is a good idea in any case, because likely at some stage your
> > database needs will increase and you can then transparently deal with
> > adding more hosts to deal with the load. (Apart from the idea that the
> > database server is on the internal network only and the web-host is open
> > to the world.)
> 
> Yeah, but the above answer is only helpful in limited circumstances,
> and unfortunately if it were applicable in all circumstances then
> I wouldn't have needed to ask the question in the first place.

Uhm, I would have thought that separation of services would be an
obvious method to secure your infrastructure.


> > >  - Using authentication systems where the user-supplied credentials are
> > >    both necessary and sufficient, so that breach of the source code is
> > >    insufficient to breach the databases.
> > Well, that only changes the point of authentication, because at some
> > point somewhere a password or credential needs to be stored. Unless of
> > course I'm missing what you're saying.
> 
> Sounds like you are missing it.

User supplied credentials can only mean two things:
      * The user supplies credentials at execution time by way of a
        password prompt of some sort.
      * The client supplies credentials in the source code or with some
        external application that authenticates on behalf of the client.

If you are talking about the latter, then my point stands. If you are
talking about the former, you are allowing database access by way of
credentials of a created user. Unless you do that manually for each
client's user, a password needs to be stored somewhere.

The script that creates accounts that can execute scripts itself will
need access to the database.

Accounts that have access need to be created. Only the client can do
that.

Eg. My point still stands. It only changes the point of authentication,
either by the database, or by the script. It doesn't actually make
anything more secure at all...


> > Well, while this may still have issues, this is how I understand it to
> > work with my host: (I'm not sure if I'm accurate or if I missed any
> > steps here either!)
> > 
> >       * Clients can only upload scripts to an upload server which only
> >         mounts the web directory that you own when you log-in. This
> >         stops casual access to other people's files.
> >       * The web server runs with BSD chroot environments for each of the
> >         clients who can do what ever they damn well like without
> >         affecting anyone else.
> 
> Would that involve 100 Apache instances in 100 chroot environments for
> 100 users, or is it less intensive than that?

IMHO it doesn't matter because if no clients are connecting to the
web-site, the instances are doing nothing. If however they are all
serving users, they're all working and you'd need to be able to run them
all at the same time anyway.


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