On Fri, May 21, 2010 at 6:40 AM, Sam Mason wrote:
> On Thu, May 20, 2010 at 09:33:23PM -0500, Peter Hunsberger wrote:
>> On Thu, May 20, 2010 at 8:03 PM, Richard Walker
>> wrote:
>> > If the hacker gets root access so they can read
>> > the raw database files, they most likely also
>> > have acc
On Thu, May 20, 2010 at 09:33:23PM -0500, Peter Hunsberger wrote:
> On Thu, May 20, 2010 at 8:03 PM, Richard Walker
> wrote:
> > If the hacker gets root access so they can read
> > the raw database files, they most likely also
> > have access to the means to decrypt any
> > encrypted data. This i
On Thu, May 20, 2010 at 11:29 PM, Richard Walker wrote:
>
> If I understand your scheme, this works in a scenario
> where the row being updated is in some sense "owned" by a
> particular user, who must provide some other data (a "password")
> not otherwise stored in the database in order
> to decr
Peter Hunsberger wrote:
Can you use an external key store? If not, I can't see this as being
a serious attempt at security, but playing along, you could try
something like the following:
1) Symmetrically encrypt a randomly generated string with something
based on the users credentials (user nam
On Thu, May 20, 2010 at 8:03 PM, Richard Walker wrote:
> Peter Hunsberger wrote:
>>
>> If you really need security of some form at the physical database
>> level then don't screw around with convoluted hacks. Â Encrypt the
>> critical data in the database and be done with it.
>
> If the hacker gets
Alvaro Herrera wrote:
Excerpts from Richard Walker's message of jue may 20 02:19:17 -0400 2010:
(a) (ii) It seems a breach is possible via the xmin values.
In that case, what about doing updates inside a transaction
that does a trivial update of all rows, e.g.:
begin transaction;
update m
Peter Hunsberger wrote:
If you really need security of some form at the physical database
level then don't screw around with convoluted hacks. Encrypt the
critical data in the database and be done with it.
If the hacker gets root access so they can read
the raw database files, they most likely
Excerpts from Richard Walker's message of jue may 20 02:19:17 -0400 2010:
> (a) (ii) It seems a breach is possible via the xmin values.
> In that case, what about doing updates inside a transaction
> that does a trivial update of all rows, e.g.:
>begin transaction;
>update mytable ; --
On Thu, May 20, 2010 at 1:19 AM, Richard Walker wrote:
>
> I have an application in which I want it
> _not_ to be possible to work out which
> rows of a table are being/have been updated.
>
Why?
If you really need security of some form at the physical database
level then don't screw around with
I have an application in which I want it
_not_ to be possible to work out which
rows of a table are being/have been updated.
I can think of these different compromise scenarios:
(a) Hacker can connect to the database to
execute queries.
The severity depends on which database user
the
10 matches
Mail list logo
