Just to make things clearer, you have a few ways of doing auth:
1. Client-side based solution (HTTP Auth, cookies, GET...)
2. Server-side based solution (sessions)
In those approaches, from what I understand, the username/password is
stored "somewhere" and communicated back to the postgresql server at
every request. I assume there's no other way around that.
Approach 1
----------
Approach 1 is the HTTP Auth, Cookies or GET solution, which is pretty
much the same thing: challenge the client, which provides the
username/password back, *at every hit*.
There are way to mitigate the security issues surrounding that approach.
One that I can think of real quick is to *encrypt* the password using a
server-side token that is stored in a sessions table. When the user
sends its credentials in the first time, it gets encrypted and is sent
back (through GET or cookies). Everytime the user comes back, that
password is decrypted and channeled through pgsql. The encrypted
password is nevery stored in the database, but will fly all around the
place, over hopefelly SSL-secured connections.
This workaround of course doesn't really work with HTTP Auth, although
the non-Basic HTTP Auth mecanisms have a similar feature.
There are also javascript-based encryption scheme that can do similar
tricks. The SPIP CMS is a good example of how to do that.
Approach 2
----------
Approach 2 is the other way around. We only communicate a session to the
user (a bit the way PHP sessions work) and store whatever credentials we
want in a server-side session table. Notice how this differs from the
above in that the credentials are explicitely stored in a ledger
database/session table.
Conclusion
----------
I think that it really depends on where you put your trust. Keep
passwords on the client or server side? Note that you don't have to keep
it in clear text anywhere, as both can use tokens to encrypt (and then
decrypt) the credentials.
We're basically stuck with those two approaches because of the way the
web works (ie. no built-in client-side session system). Note that we
*could* keep the pgsql passwords in-memory if we would use mod_perl or
similar, but that would just be another way of putting approach 2...
--
Wherever they's a fight so hungry people can eat, I'll be there.
Wherever they's a cop beatin' up a guy, I'll be there.
If Casy knowed, why, I'll be in the way guys yell when they're mad an'
I'll be in the way kids laugh when they're hungry an' they know
supper's ready. An' when our folks eat the stuff they raise an' live
in the house they build, why I'll be there.
- John Steinbeck, The Grapes of Wrath
Attachment:
signature.asc
Description: Digital signature