On Mon, Apr 02, 2018 at 12:46:25PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > I agree the attack is less likely to be applicable in typical database
> > installations. I think we should move forward with considering protocol
> > compression proposals, but any final result should put a warning in the
> > documentation that using compression is potentially insecure.
>
> It seemed like the attack you described wasn't all that dependent on
> whether the data is compressed or not:
I think it is.
I wrote something longer about this in 2013.
https://www.postgresql.org/message-id/20130115172253.GA6662@isc.upenn.edu
The key idea is you can now to a radix search of a secret rather than a
single 1-bit match/doesn't match oracle type attack which is not
feasible when you have an high entropy low density value like a big
ascii number or hex string.
I do something like set my preferred email (or anything an application
lets a user change) to something like a3bf and keep extending the guess
as I go and sometimes I compress along with the secret and rather than
have to guess a whole application session id all at once and have a work
factor of O(2^128) or something I've got a very tractable search.
It might not be something that a problem for everyone, but in some
situations it's attackable.
Garick
