Re: When to encrypt - Mailing list pgsql-general

From Jan Wieck
Subject Re: When to encrypt
Date
Msg-id 41B4A2A7.8080505@Yahoo.com
Whole thread Raw
In response to Re: When to encrypt  (Derek Fountain <dflists@iinet.net.au>)
List pgsql-general
On 12/6/2004 1:33 AM, Derek Fountain wrote:
> On Monday 06 December 2004 12:31, you wrote:
>> Derek Fountain <dflists@iinet.net.au> writes:
>> > If another SQL Injection vulnerability turns up (which it might, given
>> > the state of the website code),
>>
>> You will never see another SQL injection vulnerability if you simply switch
>> to always using prepared queries and placeholders.
>
> <much wisdom snipped>
>
> Indeed, but I'm still interested in the general answer. The server I have been
> looking at was hopelessly insecure and SQL injection is only one of its
> problems. There were several other ways in! Assume, for example, an attacker
> can write his own script directly into the website document tree. In this
> case prepared queries don't help protect what's in the database. The attacker
> can use them himself if he likes!

I don't quite see how encrypted storage of data can solve your problem.
Somehow the web application must be able to unlock/decrypt the data.
Either on a per session level, or by passing in a key with every query.
Giving out the encrypt/decrypt keys to the end users, so that they have
to supply them at login time, is probably as secure as putting them in
cleartext onto the homepage. So they must be stored readable somewhere
by the middleware system.

It does obscure the data a little more. At the same time it might give
the Web application developer a completely false feeling of security.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

pgsql-general by date:

Previous
From: "PostgreSQL general mail list"
Date:
Subject: immutable stable volatile
Next
From: Tom Lane
Date:
Subject: Re: immutable stable volatile