Thread

Re: [HACKERS] Query cancel and OOB data

Maurice Gittens <mgittens@gits.nl> — 1998-05-24T11:43:41Z

>
>However, in thinking about it, I don't think there is any way to avoid
>your solution of pid/secret key.  The postmaster, on receiving the
>secret key, can send a signal to the backend, and the query will be
>cancelled.  Nothing will be sent along the backend/client channel.  All
>other interfaces that want cancel handling will have to add some code
>for this too.
>


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".

A one-way function is expected to make it computationaly infeasible to
deduce the password given the secretkey. One-way functions (SHA1, MD5) are
also quite fast. (If I'm not mistaken these functions are allowed to be
exported
from the US. )

By including a cancel request id (together with the user password) with the
information being hashed (by the one-way function) it is also possible to
detect (and avoid) denial of service attacks
(which are based on replaying the cancel request secret keys).

This does however imply that a certain amount of extra booking is needed.

With regards from Maurice.