-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: zondag 24 mei 1998 23:52
Subject: Re: [HACKERS] Query cancel and OOB data
>"Maurice Gittens" <mgittens@gits.nl> writes:
>> Assuming that every user has a password which is known by both the client
>> and the server, it seem to me like using a one-way function based on the
>> clientuser password as the secret key (refered to above) is appropiate.
>> This avoids the need for introducing "yet another shared secret into the
>> system".
>
>Well, I think that the cancel security mechanism ought to be per backend
>process, not per user.
I assumed that this was understood.
> That is, simply being the same "Postgres user"
>should not give you the ability to issue a cancel; you ought to be
>required to have some direct association with a particular client/backend
>session. Access to the client/backend connection channel is one way;
>knowledge of a per-connection secret is another.
>
>Also, isn't it true that not all the supported authentication mechanisms
>use a password? Taking this approach would mean we have to design a new
>cancel security mechanism for each authentication protocol.
This may be true. The point I'm trying to make is that using one
way-functions
together with a shared secret will make it possible to avoid denial of
service attacks
which rely on replaying the "magic token".
Again I assumed it to be understood that the pid of the particular backend
would exchanged with the client during the initial handshake. It would also
be included (together with the shared secret e.g. the password and
and some form of a sequence id) in the one-way hash.
>
> regards, tom lane
Regards, Maurice.