Re^2: Securing the database password for web applications

That's often impractical for web applications, because:

You need a lot of system accounts
You need a lot of home directories
You need a lot of database connections

For number 3, you need one connection per user. Under mod_perl+Apache::DBI, those connections stay open, but that inevitably leaves a lot of connections open that aren't being used. That's a lot of wasted memory. Preferably, you have exactly one connection per database.

So this solution simply doesn't scale.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Comment on Re^2: Securing the database password for web applications

Replies are listed 'Best First'.
Re^3: Securing the database password for web applications by tirwhan (Abbot) on Mar 08, 2005 at 22:52 UTC
That depends on your authentication mechanism and authorisation model. If you have a small number of users it's a non-issue. If you have a larger number of users but small number of database users (aka authorisation groups) the HTTP user should not be identical with your webapp user, instead you have one apache user for each level of authorisation you want to give. You receive the HTTP authentication header, use your own method of authenticating the user, then set the HTTP user to be your database/system user. That way, you can have a different HTTP user for, say, admin, user and guest and each of these will only have access to their own database passwords. If you have a large number of database users you are entirely correct, my solution doesn't scale and you should do something else.	[reply]

Replies are listed 'Best First'.

Re^3: Securing the database password for web applications
by tirwhan (Abbot) on Mar 08, 2005 at 22:52 UTC

That depends on your authentication mechanism and authorisation model.

If you have a small number of users it's a non-issue.
If you have a larger number of users but small number of database users (aka authorisation groups) the HTTP user should not be identical with your webapp user, instead you have one apache user for each level of authorisation you want to give. You receive the HTTP authentication header, use your own method of authenticating the user, then set the HTTP user to be your database/system user. That way, you can have a different HTTP user for, say, admin, user and guest and each of these will only have access to their own database passwords.
If you have a large number of database users you are entirely correct, my solution doesn't scale and you should do something else.

[reply]