On 16 October 2014 01:29, Claudio Freire wrote:
> But in any case, if the deterrence isn't enough, and you get attacked,
> anything involving redaction as fleshed out in the OP is good for
> nothing. The damage has been done already. The feature doesn't
> meaningfully slow down extraction of data
On Wed, Oct 15, 2014 at 8:59 PM, Simon Riggs wrote:
> On 15 October 2014 21:03, Claudio Freire wrote:
>
>>> So you're familiar then with this process? So you know that an auditor
>>> would trigger an investigation, resulting in deeper surveillance and
>>> gathering of evidence that ends with vari
On 15 October 2014 21:03, Claudio Freire wrote:
>> So you're familiar then with this process? So you know that an auditor
>> would trigger an investigation, resulting in deeper surveillance and
>> gathering of evidence that ends with various remedial actions, such as
>> court. How would that proc
On Wed, Oct 15, 2014 at 4:59 PM, Simon Riggs wrote:
> On 15 October 2014 20:41, Claudio Freire wrote:
>> On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote:
>>> On 10 October 2014 16:45, Rod Taylor wrote:
>>> Redaction prevents accidental information loss only, forcing any loss
>>> that occurs
On 15 October 2014 20:41, Claudio Freire wrote:
> On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote:
>> On 10 October 2014 16:45, Rod Taylor wrote:
>> Redaction prevents accidental information loss only, forcing any loss
>> that occurs to be explicit. It ensures that loss of information can be
On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote:
> On 10 October 2014 16:45, Rod Taylor wrote:
> Redaction prevents accidental information loss only, forcing any loss
> that occurs to be explicit. It ensures that loss of information can be
> tied clearly back to an individual, like an ink pack
On 15 October 2014 19:46, Robert Haas wrote:
>> In IT terms, we're looking at controlling and reducing improper access
>> to data by an otherwise Trusted person. The only problem is that some
>> actions on data items are allowed, others are not.
>
> Sure, I don't disagree with any of that as a ge
On Wed, Oct 15, 2014 at 4:04 AM, Simon Riggs wrote:
> On 14 October 2014 17:43, Robert Haas wrote:
>> On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs wrote:
>>> As soon as you issue the above query, you have clearly indicated your
>>> intention to steal. Receiving information is no longer accidenta
On 14 October 2014 17:43, Robert Haas wrote:
> On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs wrote:
>> As soon as you issue the above query, you have clearly indicated your
>> intention to steal. Receiving information is no longer accidental, it
>> is an explicit act that is logged in the auditing
On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs wrote:
> As soon as you issue the above query, you have clearly indicated your
> intention to steal. Receiving information is no longer accidental, it
> is an explicit act that is logged in the auditing system against your
> name. This is sufficient to
On 10/10/14 21:57, Simon Riggs wrote:
Postgres currently supports column level SELECT privileges.
1. If we want to confirm a credit card number, we can issue SELECT 1
FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
2. If we want to look for card fraud, we need to be able to use t
On Sat, Oct 11, 2014 at 09:51:28AM +0100, Simon Riggs wrote:
> > So it's not actually suitable for the example you gave. I don't think we
> > want this feature...
>
> The full quote I read is the following...
>
> "Even though Oracle Data Redaction is not intended to protect against
> attacks by d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2014 02:40 AM, Simon Riggs wrote:
> As soon as you issue the above query, you have clearly indicated
> your intention to steal. Receiving information is no longer
> accidental, it is an explicit act that is logged in the auditing
> system a
On 10 October 2014 11:27, Heikki Linnakangas wrote:
> I googled for Oracle Data redaction, and found "General Usage guidelines":
>
>> General Usage Guidelines
>>
>> * Oracle Data Redaction is not intended to protect against attacks by
>> privileged database users who run ad hoc queries directly a
On 10 October 2014 16:45, Rod Taylor wrote:
> On my laptop I can pull all 10,000 card numbers in less than 1 second.
Right. Like I said: covert channels exist. Great example of how to
exploit them, thanks. Cool SQL.
What could be the use of "a security feature that does not prevent security"?
On 10 October 2014 19:26, Bruce Momjian wrote:
> On Fri, Oct 10, 2014 at 02:05:05PM +0100, Thom Brown wrote:
>> On 10 October 2014 13:43, Simon Riggs wrote:
>> > On 10 October 2014 11:45, Thom Brown wrote:
>> >
>> >> To be honest, this all sounds rather flaky.
> My other concern is you must hav
Rod,
* Rod Taylor (rod.tay...@gmail.com) wrote:
> For fun I gave the search a try.
Neat!
> On my laptop I can pull all 10,000 card numbers in less than 1 second. For
> a text based item I don't imagine it would be much different. Numbers are
> pretty easy to work with though.
I had been plannin
On Fri, Oct 10, 2014 at 02:05:05PM +0100, Thom Brown wrote:
> On 10 October 2014 13:43, Simon Riggs wrote:
> > On 10 October 2014 11:45, Thom Brown wrote:
> >
> >> To be honest, this all sounds rather flaky.
> >
> > To be honest, suggesting anything at all is rather difficult and I
> > recommend
Thom Brown wrote:
> On 10 October 2014 15:56, Stephen Frost wrote:
>> Thom Brown (t...@linux.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
On Fri, Oct 10, 2014 at 10:56 AM, Stephen Frost wrote:
> * Thom Brown (t...@linux.com) wrote:
> > On 10 October 2014 12:45, Stephen Frost 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
>
On Fri, Oct 10, 2014 at 11:58 AM, Stephen Frost 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
On 10 October 2014 15:56, Stephen Frost wrote:
> * Thom Brown (t...@linux.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-c
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Oct 10, 2014 at 7:00 AM, Stephen Frost wrote:
> > The discussion about looking up specific card numbers in the original
> > email from Simon was actually an allowed use-case, as I understood it,
> > not a risk concern. Indeed, if you
* Thom Brown (t...@linux.com) wrote:
> On 10 October 2014 12:45, Stephen Frost 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
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> You said above that it's OK to pass the card numbers to leakproof
> functions. But if you allow that, you can write a function that
> takes as argument a redacted card number, and unredacts it (using
> the < and = operators in a binary search)
On Fri, Oct 10, 2014 at 5:57 AM, Simon Riggs wrote:
>
> 1. If we want to confirm a credit card number, we can issue SELECT 1
> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
> ...
> 3. We want to block the direct retrieval of card numbers for
> additional security.
> In some cases,
On 10 October 2014 13:43, Simon Riggs wrote:
> On 10 October 2014 11:45, Thom Brown wrote:
>
>> To be honest, this all sounds rather flaky.
>
> To be honest, suggesting anything at all is rather difficult and I
> recommend people try it.
I have, and most ideas I've had have been justifiably shot
On Fri, Oct 10, 2014 at 7:00 AM, Stephen Frost wrote:
> * Thom Brown (t...@linux.com) wrote:
>> To be honest, this all sounds rather flaky. Even if you do rate-limit
>> their queries, they can use methods that avoid rate-limiting, such as
>> recursive queries. And if you're only after one credit
On 10 October 2014 12:01, Heikki Linnakangas wrote:
> Really, I don't see how this can possible be made to work. You can't allow
> ad hoc processing of data, and still avoid revealing it to the user.
Anyone with unmonitored access and sufficient time can break through security.
I think that is
On 10 October 2014 11:45, Thom Brown wrote:
> To be honest, this all sounds rather flaky.
To be honest, suggesting anything at all is rather difficult and I
recommend people try it.
Everything sounds crap when you didn't think of it and you've given it
an hour's thought.
I'm not blind to the d
On 10 October 2014 12:45, Stephen Frost wrote:
>> >> This gives the vague impression of security, but it really seems just
>> >> the placing of a few obstacles in the way.
>> >
>> > One might consider that all security is just placing obstacles in the
>> > way.
>>
>> There's a difference between i
On 10/10/2014 02:27 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 10/10/2014 02:05 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 10/10/2014 01:35 PM, Stephen Frost wrote:
Regarding functions, 'leakproof' functions should
* Thom Brown (t...@linux.com) wrote:
> On 10 October 2014 12:00, Stephen Frost wrote:
> > The discussion about looking up specific card numbers in the original
> > email from Simon was actually an allowed use-case, as I understood it,
> > not a risk concern. Indeed, if you know a valid credit car
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 10/10/2014 02:05 PM, Stephen Frost wrote:
> >* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> >>On 10/10/2014 01:35 PM, Stephen Frost wrote:
> >>>Regarding functions, 'leakproof' functions should be alright to allow,
> >>>though Heik
On 10 October 2014 12:00, Stephen Frost wrote:
> * Thom Brown (t...@linux.com) wrote:
>> To be honest, this all sounds rather flaky. Even if you do rate-limit
>> their queries, they can use methods that avoid rate-limiting, such as
>> recursive queries. And if you're only after one credit card n
On 10/10/2014 02:05 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 10/10/2014 01:35 PM, Stephen Frost wrote:
Regarding functions, 'leakproof' functions should be alright to allow,
though Heikki brings up a good point regarding binary search being
possible in a
On 10/10/2014 11:38 AM, Simon Riggs wrote:
> On 10 October 2014 10:29, Heikki Linnakangas wrote:
>> On 10/10/2014 11:57 AM, Simon Riggs wrote:
>>> Postgres currently supports column level SELECT privileges.
>>>
>>> 1. If we want to confirm a credit card number, we can issue SELECT 1
>>> FROM custo
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 10/10/2014 01:35 PM, Stephen Frost wrote:
> >Regarding functions, 'leakproof' functions should be alright to allow,
> >though Heikki brings up a good point regarding binary search being
> >possible in a plpgsql function (or even directly by
On 10/10/2014 01:35 PM, Stephen Frost wrote:
Regarding functions, 'leakproof' functions should be alright to allow,
though Heikki brings up a good point regarding binary search being
possible in a plpgsql function (or even directly by a client). Of
course, that approach also requires that you ha
* Thom Brown (t...@linux.com) wrote:
> To be honest, this all sounds rather flaky. Even if you do rate-limit
> their queries, they can use methods that avoid rate-limiting, such as
> recursive queries. And if you're only after one credit card number
> (to use the original example), you'd get it i
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 10/10/2014 01:21 PM, Simon Riggs wrote:
> >Redaction is now a feature available in other databases. I guess its
> >possible its all smoke and mirrors, but thats why we discuss stuff
> >before we build it.
>
> I googled for Oracle Data reda
On 10 October 2014 11:35, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> The requirement for redaction cannot be provided by a view.
>>
>> A view provides a single value for each column, no matter whether it
>> is used in SELECT or WHERE clause.
>>
>> Redaction r
Hi
2014-10-10 10:57 GMT+02:00 Simon Riggs :
> Postgres currently supports column level SELECT privileges.
>
> 1. If we want to confirm a credit card number, we can issue SELECT 1
> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
>
> 2. If we want to look for card fraud, we need to
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> The requirement for redaction cannot be provided by a view.
>
> A view provides a single value for each column, no matter whether it
> is used in SELECT or WHERE clause.
>
> Redaction requires output formatting only, but unchanged for other p
On 10/10/2014 01:21 PM, Simon Riggs wrote:
Redaction is now a feature available in other databases. I guess its
possible its all smoke and mirrors, but thats why we discuss stuff
before we build it.
I googled for Oracle Data redaction, and found "General Usage guidelines":
General Usage Guide
On 10 October 2014 11:08, Damian Wolgast wrote:
>
>> The problem there is that the SQL for (2) changes frequently, so we
>> want to give people SQL access.
>
> So you want to give people access to your SQL database and worry that they
> could see specific information (credit card numbers) in plai
> The problem there is that the SQL for (2) changes frequently, so we
> want to give people SQL access.
So you want to give people access to your SQL database and worry that they
could see specific information (credit card numbers) in plain and therefore you
want to format it, so that people ca
On 10 October 2014 10:15, Thom Brown wrote:
> On 10 October 2014 09:57, Simon Riggs wrote:
>> Postgres currently supports column level SELECT privileges.
>>
>> 1. If we want to confirm a credit card number, we can issue SELECT 1
>> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
>>
On 10 October 2014 10:29, Heikki Linnakangas wrote:
> On 10/10/2014 11:57 AM, Simon Riggs wrote:
>>
>> Postgres currently supports column level SELECT privileges.
>>
>> 1. If we want to confirm a credit card number, we can issue SELECT 1
>> FROM customer WHERE stored_card_number = '1234 5678 5344
>
>This would have other uses as well, such as default report formats, so
>we can store financial amounts as NUMERIC, but format them on
>retrieval as $12,345.78 etc..
Nice idea, but what if you need to do further calculations?
If you output the value of credit card transactions it works fine, b
On 10/10/2014 11:57 AM, Simon Riggs wrote:
Postgres currently supports column level SELECT privileges.
1. If we want to confirm a credit card number, we can issue SELECT 1
FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
2. If we want to look for card fraud, we need to be able to
On 10 October 2014 09:57, Simon Riggs wrote:
> Postgres currently supports column level SELECT privileges.
>
> 1. If we want to confirm a credit card number, we can issue SELECT 1
> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
>
> 2. If we want to look for card fraud, we need to
On Fri, Oct 10, 2014 at 9:57 AM, Simon Riggs wrote:
> Postgres currently supports column level SELECT privileges.
>
> 1. If we want to confirm a credit card number, we can issue SELECT 1
> FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
>
> 2. If we want to look for card fraud, we n
Postgres currently supports column level SELECT privileges.
1. If we want to confirm a credit card number, we can issue SELECT 1
FROM customer WHERE stored_card_number = '1234 5678 5344 7733'
2. If we want to look for card fraud, we need to be able to use the
full card number to join to transacti
54 matches
Mail list logo
