From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Maurice Gittens" <mgittens(at)gits(dot)nl> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Query cancel and OOB data |
Date: | 1998-05-25 16:01:31 |
Message-ID: | 7048.896112091@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Maurice Gittens" <mgittens(at)gits(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-05-25 16:14:28 | Re: [HACKERS] Query cancel and OOB data |
Previous Message | Michael Meskes | 1998-05-25 14:22:16 | Connect string again |