>
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> > on the other hand, a packet sniffer can also grab your password,
> > make his own connection to the server, and wreak much more havoc
> > than just issuing a cancel. I don't see that this adds any
> > vulnerability that wasn't there before.
>
> Ahem. Not true for those of us who use Kerberos authentication.
> We never send our passwords over the network, instead using them
> as (part of) a key that's used to encrypt other data.
OK, lets review this, with thought about our various authentication
options:
trust, password, ident, crypt, krb4, krb5
As far as I know, they all transmit queries and results as clear text
across the network. They encrypt the passwords and tickets, but not the
data. [Even kerberos does not encrypt the data stream, does it?]
So, if someone snoops the network, they will see the query and results,
and see the cancel secret key. Of course, once they see the cancel
secret key, it is trivial for them to send that to the postmaster to
cancel a query. However, if they are already snooping, how much harder
is it for them to insert their own query into the tcp stream? If it is
as easy as sending the cancel secret key, then the additional
vulnerability of being able to replay the cancel packet is trivial
compared to the ability to send your own query, so we don't loose
anything by using a non-encrypted cancel secret key.
Of course, if the stream were encrypted, they could not see the secret key
needs to be accepted and sent in an encrypted format.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)