Re: Column Redaction

On Fri, Oct 10, 2014 at 11:58 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> You are obviously wearing your rose-colored glasses this morning. I
>> predict a competent SQL programmer could write an SQL function, or
>> client-side code, to pump the data out of the database using binary
>> search in milliseconds per row.
>
> Clearly, if we're unable to prevent that, then this feature wouldn't be
> useful. What would be helpful is to consider what we could provide
> along these lines without allowing the data to be trivially recovered.

Joins are way too powerful to allow arbitrary joins to untrusted users.

The only somewhat secure way is to allow administrators define which
joins are possible, and untrusted users use those.

You get that with views. I'm not sure you can allow more than that,
and not have lots of leaks.

Is there a use case where redaction is the only solution really?

Nothing mentioned till now really is:

* Transaction logs and blocked card lists can be joined against users
and a view can be provided that includes the user, and not the credit
card. So you can join freely between the views just fine, by user, and
do all the analysis you need without exposing credit card numbers in
any way, not even redacted.

* If not users, you can join against a random but unique per card
value generated at some point when the card is first inserted in the
records, and you get a random token for the card. Still works, and can
be done with triggers, and is far less leaky than the proposed
redaction.

* Credit card number verification is a leak on its own, but if you
really want it, you can provide a function that does it. And I think
it's perfectly reasonable that defining leaking functions has to be an
admin thing.

* Views can expose the redacted value just fine for direct use. A
generically usable user-id or random-token to redacted number mapping
view would provide all the freedom you could want.

* Functions defined as leakproof (even when they're not, which is an
admin decision to throw data safety out the window, but it's a
possible decision), which allows fetching redacted columns that way
from security barrier views.

Is there anything not covered by the above that can be done by
built-in redacting?

If the answer is yes, then maybe the feature has value.

If the feature's value is ease of use, I'd weight that with the
security loss. False sense of security is a net security loss in most
(if not all) cases. Having to flesh out the logic through security
barrier views, leakproof redacting functions and triggers can have the
good side-effect of making all the possible leaks obvious to the
admin.

On Fri, Oct 10, 2014 at 12:27 PM, Thom Brown <thom(at)linux(dot)com> wrote:
> 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.

Well, that's why encryption is usually regulatorily required on credit
card data. Way too many ways to leak, and way too valuable to expect
lack of knowledgeable and motivated people trying to get them.

On Fri, Oct 10, 2014 at 12:27 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>>> 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.

Lately, the security of password-based authentication is being put
into question very often. So I wouldn't hold credit card numbers or
any other sensible information to the password standard.

But lets use the password example: it's widely accepted that holding
onto cleartext passwords or even transmitting over any channel them or
their plain hashes to be extremely bad practice. So redaction isn't
good enough for passwords, nor is salted hashing either. The only
generally accepted way on the security community, is a password proof
in the context of a zero-knowledge password proof protocol[0]. You'd
want something like that for any bit of info you need to "join" or
"compare" but you can't accept leaking it.

[0] http://en.wikipedia.org/wiki/Zero-knowledge_password_proof