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

[James Devenish]

In message <1093480574.3559.23.camel at latte.internal.itmaze.com.au>
on Thu, Aug 26, 2004 at 10:36:15AM +1000, Onno Benschop wrote:
> 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...

I thought you would be one of the people who doesn't mind brevity,
especially given the tone of many of your own replies.

> 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.

I think the problem is more general than that, but it seems that what
you have described would be covered within my 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.

Okay, agreed.

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

When you said "dedicated web host", I assumed you meant either separate
hardware, or separate virtual machines. I am aware that people sometimes
pay for "web hosting" at at local ISPs, and I would be surprised if
those ISPs bought new, dedicated hardware for every new client.
Obviously, people *can* pay for dedicate hardware if they want it,
but what happens to everybody else?

> User supplied credentials can only mean two things:
>       * The user supplies credentials at execution time by way of a
>         password prompt of some sort.
> [...] 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.

I'm not quite sure what you are thinking about, but it seemed (and still
seems) that we are thinking of different issues I didn't think it was
worth attempting to explore all possible permutations.

> > >       * 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.