Re: [HACKERS] Query cancel and OOB data

"Maurice Gittens" <mgittens@gits.nl> writes:
> 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.

Ah, now I think I see your point: you want to encrypt the cancel request
so that even a packet sniffer could not generate additional cancel
requests after seeing the first one.  That seems like a good idea, but
there is still the problem of what to use for the encryption key (the
"shared secret").  A password would work in those authentication schemes
that have a password, but what about those that don't?

More generally, I think we risk overdesigning the cancel authorization
mechanism while failing to deal with systemic security issues.  Above
we are blithely assuming that a user's Postgres password is secret ...
which it is hardly likely to be against an attacker with packet-sniffing
capability.  I don't think it's worth trying to make the cancel mechanism
(alone) proof against attacks that really need to be dealt with by
using a secure transport method.

            regards, tom lane