On 10/2/07, David Tangye <..hidden..> wrote:
On 10/3/07, Ashley J Gittins <..hidden..
> wrote:
As I understand it (and I am pretty likely to get this wrong so feel free to
point that out) the only reason we have to send the user/pass on every http
request is because of the change to using postgresql to authenticate every
request (ie, server-side, LSMB logs into psql as the actual user), therefore
requiring the password to do so.
Let me try to answer this: see if I am right. (Chris?)
I am guessing that the user/password and any other session data is sent on every http request is to code in a RESTful way, ie with AJAX. This way a session's state is kept within the session, ie past back and forward with the data. The alternative is to either hold session state info on the server, in the hope that the session will be needed by future client requests, and then have to code stuff to manage this data, eg when to get rid of it, or else pass server-side info as cookies and code client side stuff to manage this data when its not needed.
The problem is specific to pass-through authentication systems. You can't do a zero-knowledge authentication challenge because the server has to pass the credentials on to another source. This is precisely the problem that Kerberos was designed to solve, but I don't want to force Kerberos down the throats of every LSMB user...
I remember trying to make the point some time ago that maybe LSMB should
connect as it's own user, then use postgres' role-switching abilities to
become the connected user after connection.
That's not clear. Are you referring to the old "each user has his own app usename + there is one db account that the app code uses" vs "each user has his own application-username=db-username".
Basically you log in with a "group" account and then use "set role" to an individual account after performing the authentication. This is fairly similar to the su command on Linux. I can see cases where this would add to our security exposure, however.
As I understand it this can be done without having to supply the user's password.
Whichever way usernames are set up, a username and password of one sort or the other still needs to be passed from the frontend to the backend at least for account creation and password changes. If this is encrypted in the frontend, then the same mechanism might as well be used to authenticate logins as well.
Using a simple hash of a password that can be compared on the backend is universally wrong and offers no better protection than submitting the plain text password over the wire. Even Windows NT 4's challenge-response authentication is vulnerable to (slightly more complex) replay attacks These systems are all very sensitive to error both in conception and implementation.
If all database access to the LSMB tables is to be via the LSMB code (or extensions) then a single db user account is fine. It is used by the application. I suppose that the source password for the application is in cleartext in the application's config file.
That is the thing though We are not using a single db user account. Every user is represented by a DB user account.
Best Wishes,
Chris Travers