Re: Column Redaction

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Thom Brown <thom(at)linux(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Damian Wolgast <damian(dot)wolgast(at)si-co(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column Redaction
Date: 2014-10-10 14:56:16
Message-ID: 20141010145616.GG28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Thom Brown (thom(at)linux(dot)com) wrote:
> On 10 October 2014 12:45, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> There's a difference between intending that there shouldn't be a way
> >> past security and just making access a matter of walking a longer
> >> route.
> >
> > Throwing random 16-digit numbers and associated information at a credit
> > card processor could be viewed as "walking a longer route" too. The
> > same goes for random key searches or password guesses.
>
> But those would need to be exhaustive, and in nearly all cases,
> impractical.

That would be exactly the idea with this- we make it impractical to get
at the unredacted information.

> 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.

> 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.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-10-10 14:58:07 Re: Column Redaction
Previous Message Stephen Frost 2014-10-10 14:53:55 Re: Column Redaction