Re: Database Encryption (now required by law in Italy)

Quoting Mitch Pirtle <mitchy(at)spacemonkeylabs(dot)com>:

> Matt Davies wrote:
>
> > And how does one account for key information? If one encrypts any
> information
> > deemed worthy to be a key then you have to decrypt the entire database to
> find
> > particular information.
> >
> >
> > Of course, you could keep keys unencrypted for use, but then again, why
> encrypt
> > it at all?
>
> My question is much more basic than that: Why encrypt anything beyond
> passwords? If you secure the accounts on the machine, and encrypt all
> network traffic to the machine (ssh, scp, ssl) then what additional
> security can you add?

I totally agree. Depending on interpretation this would totally negate the
usefullness of a database at all.

>
> I have servers in remote facilities all over the world. It is just not
> possible for me to fly to each datacenter to be there at boot time when
> I upgrade the kernel. I'd love the travel, but it is not feasible.
>
> Second, hard-disk encryption will only come into play if someone stole
> the hardware, right? And even then, as long as the thing boots, then
> they would have access! That is, unless we went back to the
> human-required-at-boot scenario.
>
> As a former CSO for an 18000-person company, I'm a horribly paranoid
> person when it comes to security; but security that is easily bypassed
> (or dificult-to-impossible to enforce) is just added effort, isn't it?
>
> Here is an idea to beat up on: how about having the end user of the
> application supply the key that is used to decrypt their data, and only
> their data? Take your basic, garden variety PHP website, for example.
>
> When the user is given an account, they are also given a password. This
> password is also used as the key for the (blowfish, via mcrypt maybe?)
> encryption of the data that gets stored for that person. If you do not
> have that key, then you cannot decrypt their data. To boot, their key
> is useless for everyone else's data as they used their own...
>

I have thought about this scenario many times. The problem then is lost
passwords and so forth. All data is then useless because you can't decrypt it.

I worked for a public certification authority at one time and we were starting
to explore key escrow. That would be a useful feature, but in the end, one
sufficiently motivated will probably find a way to circumvent the system.

> Excellent discussion, maybe we could all come up with a sort of best
> practices for PostgreSQL and security :)
>
> -- Mitch
>

Yes, excellent discussion. Security and privacy are always important, but it is
also necessary to remember the business case and use of databases and not
reduce their functionality to nil. It is a hard balance to find.