From: | Timothy Madden <terminatorul(at)gmail(dot)com> |
---|---|
To: | |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Database level encryption |
Date: | 2010-04-06 14:59:59 |
Message-ID: | g2x5078d8af1004060759t1f6e0070u288201c87f925ca2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
The machine does not have internet and it will not be trivial for the
bad guy to install anything there.
And my idea is exactly that the database is inaccessible, even if the
server starts. Unless the password is provided upon connecting or
selecting the database. You can think of it as if all columns in all
tables are ecrypted (although I would like even the number and names
of tables and schema-objects to be encrypted).
On Tue, Apr 6, 2010 at 5:36 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Timothy Madden <terminatorul(at)gmail(dot)com> wrote:
>
>> With an encrypted database, you need the password anytime you
>> connect, even if another application already has an open
>> connection.
>
> How is the database server supposed to start up and become ready to
> accept connections without reading the database?
>
> Also, as previously mentioned, if a bad guy gets hold of the machine
> while running, what prevents them from installing a daemon to record
> and transmit keystrokes after they copy the encrypted data?
>
> Perhaps an encrypted drive for the database data combined with an
> aggressive lockup policy for an idle machine would work?
>
> -Kevin
>
From | Date | Subject | |
---|---|---|---|
Next Message | Melissa Peterson | 2010-04-06 15:47:52 | Re: Database level encryption |
Previous Message | Kevin Grittner | 2010-04-06 14:36:17 | Re: Database level encryption |