Re: When to encrypt - Mailing list pgsql-general

Derek Fountain <dflists@iinet.net.au> writes:

> 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.

I would argue that never interpolating user-provided data into your query
strings _is_ the general answer. It's going through laborious case-by-case
quoting that's non-general and can fail if any single instance isn't done
properly. If you use always use placeholders then there's nothing you can fail
to do properly that would cause an injection vulnerability.

You could use something like perl's taint tracking to keep track of whether
the data used in the query string is tainted by user-provided data. This would
even let you use manual quoting since it lets you designate functions that
untaint strings. But even that seems risky to me. taintperl is liberal about
what it considers detainting. I prefer to allow only constant program-defined
strings to be used in my queries period.

> Given this type of mess, having logins, passwords, credit card info and the
> like encrypted in the DB will add another layer of protection. The question
> is, do people normally add this layer, just in case, or do they assume that
> all the previous layers will do the job?

Layers are not useful unless they're effective. You can have 10 layers of 90%
effective security but it would be worthless. You still have an insecure
system.

The only useful way to use real-time encryption for a web server is public key
encryption for write-only data like credit card numbers. Usually the web
server really doesn't need access to existing credit card data. It only needs
to be able to add new credit card data or perhaps copy existing credit card
data.

So you could have the web server encrypt the credit card numbers using RSA and
store them in the database. Then only the credit card processing job which
might run on a highly secure dedicated box would pull the data and use the
private key to process the transactions.

The nice thing about this is that it isn't going to stop your web server or
database from being cracked, but it will limit the damage. The attacker can't
download a database of your entire customer base's credit card numbers.

Personally I think this is the only responsible way to run a system that keeps
credit card data. But sadly the rest of the world doesn't seem to agree.

By contrast, encryption is useful for non-live data such as database backups.
This lets you take them off-site and store them someplace without worrying
about someone walking off with your entire database. Or to discard the tapes
without worrying about someone reading your old data from the discarded tapes.
(Assuming of course that you don't write the key on the label...)

--
greg