Обсуждение: password cookie
Hi,
I´m envolved in developping a website that will function as a frontend for psql 8.1 cluster.
We use a number of frontend technologies, and we want to keep the authentication in the backend. Not a system where the frontend queries a table to verify username password, sets the priviliges on the front end and logs in as a superuser on the backend. So we need to have username and password ready at a lot of moments, too many for a user to type it in all the time.
Since we´re on a very tight time schema, we don´t want to implemt LDAP just yet, since it will complicate things (even) more. Especially synchronising user (role) changes between PostgreSQL and the LDAP server seems tricky, since the database cluster stills keeps its pg_authid tables (right?).
So as a temporary compromise, we decided to store the username and password in a cookie on the client PC, which is of course a serious weakness.
Can anyone give me some advise on how to do this a better way, without consuming too much time, or is this the best thing to do in such a situation?
I´m envolved in developping a website that will function as a frontend for psql 8.1 cluster.
We use a number of frontend technologies, and we want to keep the authentication in the backend. Not a system where the frontend queries a table to verify username password, sets the priviliges on the front end and logs in as a superuser on the backend. So we need to have username and password ready at a lot of moments, too many for a user to type it in all the time.
Since we´re on a very tight time schema, we don´t want to implemt LDAP just yet, since it will complicate things (even) more. Especially synchronising user (role) changes between PostgreSQL and the LDAP server seems tricky, since the database cluster stills keeps its pg_authid tables (right?).
So as a temporary compromise, we decided to store the username and password in a cookie on the client PC, which is of course a serious weakness.
Can anyone give me some advise on how to do this a better way, without consuming too much time, or is this the best thing to do in such a situation?
On Wed, Oct 25, 2006 at 03:49:54PM +0200, Willy-Bas Loos wrote:
> So as a temporary compromise, we decided to store the username and password
> in a cookie on the client PC, which is of course a serious weakness.
>
> Can anyone give me some advise on how to do this a better way, without
> consuming too much time, or is this the best thing to do in such a
> situation?
The usual workaround I'm familiar with is to set a hash of some sort
that is the user, password, and some salt. Then you authenticate
against that hash in your application, so that you never actually
send these values, nor store them anywhere except the database.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
I think that´s not exactly what i´m looking for.
Just to make sure that i understand what you´re proposing (please correct me if i´m wrong):
I´ll write a function that will create a hash of username, password and, say 'now'::timestamp and store it in a cookie and in a separate table somewhere on the cluster, if authentication is succesfull.
Then, upon every need for authorisation, the frontend will log into the database as a highly priviliged user (or allready be logged in), and compare the hashed values. If they are equal, it will allow certain actions.
After some time, i´ll trigger to delete the hash from the database.
I could still store the user name on the back end, and retreive it with the provided hash, so that i know what actions to allow. I would then fake postgreSQL´s authentication by querying the rights and roles for this user.
The problem is that the frontend would in fact have to be some major user that regulates all authorisation, and the password for it would have to be stored on the webserver.
What i am looking for is this:
Every time the user / frontend asks for certain data (or actions), he will or will not receive those, because of the rights granted to him. These granted rights and roles will be determined by the regular postgres functionality (and some views).
The frontend does have a low priviliged username and password stored in it, just to access the web-content.
WBL
Just to make sure that i understand what you´re proposing (please correct me if i´m wrong):
I´ll write a function that will create a hash of username, password and, say 'now'::timestamp and store it in a cookie and in a separate table somewhere on the cluster, if authentication is succesfull.
Then, upon every need for authorisation, the frontend will log into the database as a highly priviliged user (or allready be logged in), and compare the hashed values. If they are equal, it will allow certain actions.
After some time, i´ll trigger to delete the hash from the database.
I could still store the user name on the back end, and retreive it with the provided hash, so that i know what actions to allow. I would then fake postgreSQL´s authentication by querying the rights and roles for this user.
The problem is that the frontend would in fact have to be some major user that regulates all authorisation, and the password for it would have to be stored on the webserver.
What i am looking for is this:
Every time the user / frontend asks for certain data (or actions), he will or will not receive those, because of the rights granted to him. These granted rights and roles will be determined by the regular postgres functionality (and some views).
The frontend does have a low priviliged username and password stored in it, just to access the web-content.
WBL
On 10/25/06, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
The usual workaround I'm familiar with is to set a hash of some sort
that is the user, password, and some salt. Then you authenticate
against that hash in your application, so that you never actually
send these values, nor store them anywhere except the database.
On Thu, Oct 26, 2006 at 12:27:49AM +0200, Willy-Bas Loos wrote:
> or will not receive those, because of the rights granted to him. These
> granted rights and roles will be determined by the regular postgres
> functionality (and some views).
Ah, that's a different matter. My suggestion is "don't do that".
I tried to do it once, years ago, and regretted it deeply. Of
course, my code was awful, and yours might be better. But in my
view, that's a security problem just waiting to happen. You're
better off to have one user in your application that does the
authentication for you. You can use Kerberos or something to
authenticate it; much easier to lock down one such user carefully,
that comes only from boxes under your control, than to secure many
users' accounts.
If you want to do it this way, I sure wouldn't use cookies to store
the password. I think you're asking for a compromise that way.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
> My suggestion is "don't do that".
> I tried to do it once, years ago, and regretted it deeply.
Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want to),
or "don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user" (which i do want to)?
WBL
> I tried to do it once, years ago, and regretted it deeply.
Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want to),
or "don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user" (which i do want to)?
WBL
I just learned to read, sorry.
You mean not to do the second thing, which i do want to do (where each frontend user equals a database user).
Thank you for your advise.
I´m not sure if i can get around it, but i´ll use extra caution anayway.
WBL
You mean not to do the second thing, which i do want to do (where each frontend user equals a database user).
Thank you for your advise.
I´m not sure if i can get around it, but i´ll use extra caution anayway.
WBL
On 10/27/06, Willy-Bas Loos <willybas@gmail.com> wrote:
> My suggestion is "don't do that".
> I tried to do it once, years ago, and regretted it deeply.
Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want to),
or "don´t set up your webservice so that users will recieve data according to their own rights in the database, where each frontend user equals a database user" (which i do want to)?
WBL