From: | Daniel Martini <dmartini(at)uni-hohenheim(dot)de> |
---|---|
To: | Derek Fountain <dflists(at)iinet(dot)net(dot)au> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: When to encrypt |
Date: | 2004-12-06 14:46:12 |
Message-ID: | 1102344372.41b470b42477e@webmail.uni-hohenheim.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
Citing Derek Fountain <dflists(at)iinet(dot)net(dot)au>:
> Indeed, but I'm still interested in the general answer.
There is no general answer. Depends on how deep you get into trouble, if
the data is compromised.
> The server I have been looking at was hopelessly insecure and SQL
> injection is only one of its problems. There were several othe
> 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!
A chain of security measures is only as strong as its weakest link.
If cryptography will help you in this case really depends very much on the
level of system access an attacker can gain and on the encryption scheme
you use.
If an attacker can gain root, it is quite probable, that your cryptographic
keys will be compromised (because he will very probably be able to read
physical memory), so cryptography will not help you at all.
If an attacker can not gain root, it depends on if you use encryption
on the file system level or on record level in the db. File system
level encryption does not help much against attacks from the network
on a running system, because the file system will very probably
be mounted, and thus readable. record level encryption might help,
depending on how it is implemented (when you implement it, ask yourself:
are keys/passwords which are floating around between database server/
web server/client app unreadable by eavesdroppers on all stages of
processing?)
> 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.
In general, I would, if there was medical/payment/other personal data in
the db. The country I live in has quite strict regulations concerning
protection of people's private data...
(which is a good thing IMHO. Anyways just to make the point for you, that
this is more than just a technical matter ;-) Legal matters and economics
play a role here, too.)
But discussion above and conclusion below should show you, that there's a
bunch of problems elsewhere, which cannot be solved just by using
cryptography.
> or do they assume that
> all the previous layers will do the job?
Key thing is to find the weakest layer and strengthen it. Strongest
security measure does no good, if an attacker can easily bypass it
by gaining higher level system access by breaking another (weaker)
security layer.
>From your description of the problem, I would conclude, that your
client's app needs fixing elsewhere first.
Regards,
Daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew - Supernews | 2004-12-06 15:06:59 | Re: select single entry and its neighbours using direct-acess to index? |
Previous Message | David Esposito | 2004-12-06 14:08:02 | Performance tuning on RedHat Enterprise Linux 3 |