On Fri, Apr 17, 2009 at 10:33:15AM -0400, Bill Moran wrote:
> The goal is not to trust any one part of the system.
> As a result, we can protect the data across multiple security failures.
As far as I know this isn't a good way to go about designing secure
systems. You're better off defining a se
Bill Moran wrote:
John R Pierce wrote:
Eric Soroos wrote:
an index on the encrypted SSN field would do this just fine. if
authorized person needs to find the record with a specific SSN, they
encrypt that SSN and then look up the ciphertext in the database...
done.
This
In response to Sam Mason :
>
> > As far as the trust factor, you've blurred the lines a bit. My job
> > is to ensure that the user doesn't know or care about the lines between
> > application and database, but trusts the system as a whole. However,
> > I need to clearly define those lines and en
On Fri, Apr 17, 2009 at 09:52:30AM -0400, Bill Moran wrote:
> In response to Sam Mason :
> > For example; you say that you don't trust the application, yet the user
> > must trust the application as they're entering their secret into it.
> > How does the user ascertain that the application they're
In response to Sam Mason :
> On Thu, Apr 16, 2009 at 05:06:13PM -0400, Bill Moran wrote:
> > I disagree. We're already addressing the issues of security on the
> > application level through extensive testing, data validation out the
> > wazoo (to prevent SQL Injection and other application breach
On Thu, Apr 16, 2009 at 05:06:13PM -0400, Bill Moran wrote:
> I disagree. We're already addressing the issues of security on the
> application level through extensive testing, data validation out the
> wazoo (to prevent SQL Injection and other application breaches). All
> our servers are in highl
> > Take the performance hit, If people on high want the data encrypted,
then
> > they have to suffer the performance penalty, however bad.
>
> As reasonable as that sounds, I don't think it's true. We've already
> brainstormed a dozen ways to work around the performance issue (creative
> hash
In response to chris.el...@shropshire.gov.uk:
> > What are folks doing to protect sensitive data in their databases?
> >
> > We're running on the assumption that the _really_ sensitive data
> > is too sensitive for us to just trust the front-end programs that
> > connect to it.
> >
> > The decis
> What are folks doing to protect sensitive data in their databases?
>
> We're running on the assumption that the _really_ sensitive data
> is too sensitive for us to just trust the front-end programs that
> connect to it.
>
> The decision coming down from on-high is that we need to encrypt
> cer
"Jonathan Bond-Caron" wrote:
>
> On Thu Apr 16 05:06 PM, Bill Moran wrote:
> >
> > The problem comes when the company head wants to search through the
> > database to find out which employee has a specific SSN. He should be
> > able to do so, since he has access to everything, but the logistic
John R Pierce wrote:
>
> Eric Soroos wrote:
> >> an index on the encrypted SSN field would do this just fine. if
> >> authorized person needs to find the record with a specific SSN, they
> >> encrypt that SSN and then look up the ciphertext in the database...
> >> done.
> >
> > This will o
Michael Black wrote:
>
> If the purpose of encryption is for financial or medica data transmission
> security, or something of a higher order, you may want to implement a
> stronger type of security such as SSL or PGP or some other type of
> public/private key process.
>
> You could create a
"Will Rutherdale (rutherw)" wrote:
>
> Couldn't you just add a PGP based column (or similar encryption
> protocol) for authentication? This would protect you against injection
> attacks, would it not?
>
> You could also use PGP or similar for key management if I'm not
> mistaken.
Thanks for the
That's where we're having difficulty. Our requirements are that the
data must be strongly protected, but the appropriate people must be
able to do (often complex) searches on it that complete in record
time.
an index on the encrypted SSN field would do this just fine. if
authorized pers
Thomas Kellerer wrote:
>
> Bill Moran wrote on 16.04.2009 23:06:
> >> which only talks about someone getting hold of the contents of the
> >> server's
> >> harddisk.
> >
> > Not really. You're making an assumption that a pg_dump can only be
> > run on the server itself.
>
> Right, I forgot th
Eric Soroos wrote:
an index on the encrypted SSN field would do this just fine. if
authorized person needs to find the record with a specific SSN, they
encrypt that SSN and then look up the ciphertext in the database...
done.
This will only work for e(lectronic?) code book ciphers, and
On Thu Apr 16 05:06 PM, Bill Moran wrote:
>
> The problem comes when the company head wants to search through the
> database to find out which employee has a specific SSN. He should be
> able to do so, since he has access to everything, but the logistics of
> doing so in a reasonable amount of
Apr 2009 15:40:12 -0400
> From: wmo...@potentialtech.com
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Looking for advice on database encryption
>
>
> What are folks doing to protect sensitive data in their databases?
>
> We're running on the assumption that
Bill Moran wrote:
The problem comes when the company head wants to search through the
database to find out which employee has a specific SSN. He should
be able to do so, since he has access to everything, but the logistics of
doing so in a reasonable amount of time are rather complex and very
ti
Couldn't you just add a PGP based column (or similar encryption
protocol) for authentication? This would protect you against injection
attacks, would it not?
You could also use PGP or similar for key management if I'm not
mistaken.
-Will
-Original Message-
In response to Thomas Kellerer
Bill Moran wrote on 16.04.2009 23:06:
which only talks about someone getting hold of the contents of the server's
harddisk.
Not really. You're making an assumption that a pg_dump can only be
run on the server itself.
Right, I forgot that.
But then it's similar to the situation where the use
In response to Steve Atkins :
>
> On Apr 16, 2009, at 12:40 PM, Bill Moran wrote:
>
> (This is the traditional "you're asking the wrong question" response).
>
> >
> > What are folks doing to protect sensitive data in their databases?
>
> I don't think that's a useful way to look at it. Protecti
In response to Thomas Kellerer :
> Bill Moran wrote on 16.04.2009 22:20:
> >> I'm by far not an expert, but my naive attempt would be to store the the
> >> database files in an encrypted filesystem.
> >
> > That was the first suggestion when we started brainstorming ideas.
> > Unfortunately, it
Bill Moran wrote on 16.04.2009 22:20:
I'm by far not an expert, but my naive attempt would be to store the the
database files in an encrypted filesystem.
That was the first suggestion when we started brainstorming ideas.
Unfortunately, it fails to protect us from the most likely attack
vector:
On Thu, April 16, 2009 13:20, Bill Moran wrote:
> In response to Thomas Kellerer :
>
>> Bill Moran wrote on 16.04.2009 21:40:
>> > The goal here is that if we're going to encrypt the data, it should
>> > be encrypted in such a way that if an attacker gets ahold of a dump
>> > of the database, they
On Apr 16, 2009, at 12:40 PM, Bill Moran wrote:
(This is the traditional "you're asking the wrong question" response).
What are folks doing to protect sensitive data in their databases?
I don't think that's a useful way to look at it. Protecting sensitive
data in the entire system, where th
In response to Thomas Kellerer :
> Bill Moran wrote on 16.04.2009 21:40:
> > The goal here is that if we're going to encrypt the data, it should
> > be encrypted in such a way that if an attacker gets ahold of a dump
> > of the database, they still can't access the data without the
> > passphrases
Bill Moran wrote:
What are folks doing to protect sensitive data in their databases?
I would probably do my encryption in the application layer, and only
encrypt the sensitive fields. fields used as indexes probably should
not be encrypted, unless the only index operation is EQ/NE, then
Bill Moran wrote on 16.04.2009 21:40:
The goal here is that if we're going to encrypt the data, it should
be encrypted in such a way that if an attacker gets ahold of a dump
of the database, they still can't access the data without the
passphrases of the individuals who entered the data.
I'm by
What are folks doing to protect sensitive data in their databases?
We're running on the assumption that the _really_ sensitive data
is too sensitive for us to just trust the front-end programs that
connect to it.
The decision coming down from on-high is that we need to encrypt
certain fields. T
30 matches
Mail list logo
