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