"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
