Ed Dressel wrote:

> "academic" in the sense that it sounds like a classroom
> argument, not one that is about implementation in the
> real world. No offense meant.

No offence taken... the main concern I have is that if it reads
as "academic" that people will not take it seriously. It is
very much grounded in the real world, it's central premise is
a well accepted axiom of computer security. From the conclusion
of the article:

If you are not in control of the environment (the hardware,
the operating system and all software running on that system)
then you have no control over the security

That seems pretty simple and straight-forward (and self-evident
once you sit down and think about it)... but many don't want it
to be true and keep looking for the magic beans.

>> Yes, it's called marketing. Mostly it has very little to do
>> with security issues addressed by my article.

> Only "marketing"? I would disagree if you said yes.

Note that my article is about metadata security and in such
cases I would say it was only marketing. They sell you the
idea that they are protecting developer's metadata from
legitimate users of the database but such protection is mostly
just smoke and mirrors. Closed-source systems can have secrets
that can obscure metadata in ways that would make it difficult
to extract (the first time)... open-source systems don't have
secrets.

User data security (users protecting their own data) is
possible and practical (assuming the users are in control of
their environment) and a range of products exist to do it...

>> If you sell the application to your clients as a package then
>> it should be feasible to re-package your product to install
>> TrueCrypt or similar product. This is essentially the same
>> result as if the database engine did the encryption:

> I will look into these, but I still would like to see it at
> the database level. But we can agree to disagree.

I can certainly agree that having user-data encryption features
embedded in the engine could be more convenient... but this
convenience often comes at the expense of security. There are
significant issues here about how database pages are encoded in
such encryption - issues that need to be addressed or the
encryption may be significantly weakened. Good security is
hard to get right, which is why I advocate using products whose
developers specialise in this area.

If using dedicated products like TrueCrypt is too difficult
then have the user access features available on some modern
operating systems... for example EFS on Windows. This should
be convenient (cheap if you already have the required version
of Windows) and as effective and secure as you can get without
using a more complete/dedicated product.

--
Geoff Worboys
Telesis Computing