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

I think have found an insight into what you're saying: you're describing
what might happen if each client runs services that effectively have
their own authentication realms, in which a multitude of user
credentials are being created within those realms. Yes, that is a
problem. But I'm still not sure what you mean by "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." It would certainly be useful
to have a solution to this problem, but I did not see its relevance
under the heading "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".

Also, I did not know was the point of saying "For hosting your own
solutions this is an option, but for the general population, eg. hosting
for others, this is likely not going to win you friends." I assumed that
what you're saying was true, but thought it was just a casual anecdote
of some sort.