Thread

1. Re: [HACKERS] Query cancel and OOB data

   Tom Lane <tgl@sss.pgh.pa.us> — 1998-05-25T16:01:31Z

   "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
   
   

2. Re: [HACKERS] Query cancel and OOB data

   ocie@paracel.com — 1998-05-26T21:17:16Z

   Tom Lane wrote:
   > 
   > "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?
   
   Aha!
   
   I'm slowly working through back emails, so I apologize if someone else
   already posted this.  If we want to create a shared secret between the
   postmaster and the client, we should think about the Diffe-Helman
   algorithm.  
   
   For those unfamiliar with this, we start by picking large numbers b
   and m.  The client picks a number k and then sends K=b^k%m, while the
   server picks a number l and sends L=b^l%m.  The client calculates
   L^k%m and the server calculates K^l%m, and these numbers are
   identical.  A third party eavesdropping on the conversation would only
   get K and L, and would have no idea what the shared number is, unless
   they can calculate the computationally infeasible discrete logarithm.
   
   Anyway, something to think about.
   
   Ocie