Re: Column Redaction

On 10 October 2014 15:56, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Thom Brown (thom(at)linux(dot)com) wrote:
>> Data such as plain credit card numbers stored in a
>> column, even with all its data masked, would be easy to determine.
>
> I'm not as convinced of that as you are.. Though I'll point out that in
> the use-cases which I've been talking to users about, it isn't credit
> cards under discussion.

I think credit card numbers are a good example. If we're talking
about format functions here, there has to be something in addition to
that which determines permitted comparison operations. If not, and we
were going to remove all but = operations, we'd effectively cripple
the functionality of anything that's been formatted that wasn't
intended as a security measure. It almost sounds like an extension to
domains rather than column-level functionality.

But then if operators such as <, > and ~~ aren't hindered, it sounds
like no protection at all.

Also, joining to foreign tables could be an issue, copying data to
temporary tables could possibly remove any redaction, materialised
views would need to support it somehow. Although just because I can't
picture how that would work, it's no indication that it couldn't.

>> Salted and hashed passwords, even with complete visibility of the
>> value, isn't vulnerable to scrutiny of particular character values.
>> If it were, no-one would use it.
>
> I wasn't suggesting otherwise, but I don't see it as particularly
> relevant to the discussion regardless.

I guess I was trying to illustrate that the security in a hashed
password is acceptable because it requires exhaustive searching to
break. If comparison operators worked on it, it would be broken out
of the box.

--
Thom