Database security (crosspost)

Leif B. Kristensen wrote:

> For crying out loud.

See below. Go back twenty years. "For crying out loud"?. I am sure there
will be many scenarios where the DB will go mobile for lots of good reasons.
Security will be just as important at the bank and in your hand.

> *I* for one
> expect to be carrying around a small device that will easily let me
> maintain a database through something resembling a Web interface. The
> backend and storage should be situated in a safe place, and certainly
> not in my pocket.


Thanks for all input. All interesting.

-Martin

On Fri, 09 Dec 2005 10:22:19 -0800, Bill Karwin <bill@karwin.com>
wrote:

[snip]

>Besides, if a given DBMS said it contained "security", would you feel
>comfortable trusting their implementation, if your data was truly that
>sensitive?

If they do not say that it does, I would be even less
comfortable. Trust but verify?

Sincerely,

Gene Wirchenko

> Martin wrote:
>> I'd venture to say that most db's
>> are not designed to have strong security at the file level. I understand
>> why (cpu and system load in managing constant encrypt/decrypt processing)
>> but it is disturbing nevertheless.
>>
>> -Martin
>
> SQL Server 2005 has strong encryption built in to the database. The
> user decides whether that applies to all of the database or just
> selected data.

Unfortunately, that means that you have to trust the database engine
with the cryptographic keys.

That means the DB engine is free to do whatever it likes with them,
which is an inherent, vast, gaping security hole.

It's so gaping that it obviates any value to the use of encryption.
--
output = ("cbbrowne" "@" "ntlug.org")
http://linuxdatabases.info/info/lsf.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero." <http://www.eviloverlord.com/>

Christopher Browne (cbbrowne@acm.org) writes:
> Unfortunately, that means that you have to trust the database engine
> with the cryptographic keys.
>
> That means the DB engine is free to do whatever it likes with them,
> which is an inherent, vast, gaping security hole.

Eh? The DB engine does not have a mind of its own. Of course, any piece
of software can be spyware that leaks secrets behind your backs, but
if you are that paranoid, you should not use computers at all.

Or could you care to elaborate what you actually mean?


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

Christopher Browne wrote:
> > Martin wrote:
> >> I'd venture to say that most db's
> >> are not designed to have strong security at the file level. I understand
> >> why (cpu and system load in managing constant encrypt/decrypt processing)
> >> but it is disturbing nevertheless.
> >>
> >> -Martin
> >
> > SQL Server 2005 has strong encryption built in to the database. The
> > user decides whether that applies to all of the database or just
> > selected data.
>
> Unfortunately, that means that you have to trust the database engine
> with the cryptographic keys.
>
> That means the DB engine is free to do whatever it likes with them,
> which is an inherent, vast, gaping security hole.
>
> It's so gaping that it obviates any value to the use of encryption.
> --

You mean to say that you only run open source and you inspect every
line of code that runs on your hardware? If not, how can you trust any
of it?

--
David Portas
SQL Server MVP
--

> Christopher Browne (cbbrowne@acm.org) writes:
>> Unfortunately, that means that you have to trust the database
>> engine with the cryptographic keys.
>>
>> That means the DB engine is free to do whatever it likes with them,
>> which is an inherent, vast, gaping security hole.
>
> Eh? The DB engine does not have a mind of its own. Of course, any
> piece of software can be spyware that leaks secrets behind your
> backs, but if you are that paranoid, you should not use computers at
> all.
>
> Or could you care to elaborate what you actually mean?

If risk to be mitigated is that you do not wish to trust the system
administrators with the data, then you must not give the keys to any
component that system administrators can control.

That obviously includes the database engine.
--
output = ("cbbrowne" "@" "ntlug.org")
http://linuxdatabases.info/info/lsf.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero." <http://www.eviloverlord.com/>

> Christopher Browne wrote:
>> > Martin wrote:
>> >> I'd venture to say that most db's
>> >> are not designed to have strong security at the file level. I understand
>> >> why (cpu and system load in managing constant encrypt/decrypt processing)
>> >> but it is disturbing nevertheless.
>> >>
>> >> -Martin
>> >
>> > SQL Server 2005 has strong encryption built in to the database. The
>> > user decides whether that applies to all of the database or just
>> > selected data.
>>
>> Unfortunately, that means that you have to trust the database engine
>> with the cryptographic keys.
>>
>> That means the DB engine is free to do whatever it likes with them,
>> which is an inherent, vast, gaping security hole.
>>
>> It's so gaping that it obviates any value to the use of encryption.
>
> You mean to say that you only run open source and you inspect every
> line of code that runs on your hardware? If not, how can you trust any
> of it?

That would the sort of process required to validate comprehensively that
a system is secure.

That is not my goal; I merely need to indicate the obvious *holes*.

If crypto keys are passed into the database system, there are several
blatantly obvious places where modifications could be done to capture
crypto keys.

1. If they are passed across some interface like SQL-CLI, then the
query parser will have the key in plaintext form.

Capturing crypto keys might well be as simple, in this case, as
turning on query logging, which is a pretty standard database feature.

2. It is more than likely that there will be a single,
well-identifiable crypto library to which the key must be passed.
Know the address, inside the library, and you can find the code that
uses it. And hence you can either modify the library, or add a
wrapper library, in between (e.g. - on Unix, via a mechanism like
LD_LIBRARY_PATH), which can capture the key.

These are blatantly obvious mechanisms for capturing keys; supposing
implementors try to be clever, it can become less easy, but even so,
someone with anything near to physical access to the hardware can
examine memory contents, sniff network traffic, and the like, making
it extremely difficult to *truly* hide the keys from the system
operators.

There are hardware-based crypto cards which have special provisions
for how *their* keys are populated which can, if competently operated,
in a secure physical environment, provide pretty strong tamper
resistance.

But I'd take a guess that the cost of establishing that "competently
operated secure physical environment" is on the order of hundreds of
thousands of dollars, which isn't affordable for terribly many users.
--
output = ("cbbrowne" "@" "ntlug.org")
http://linuxdatabases.info/info/lsf.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero." <http://www.eviloverlord.com/>

On Thu, 08 Dec 2005 21:08:32 +0000, Martin wrote:


> My application would more than likely be single user. It made me wonder how
> high-security DB's are handled. It seems to me that data is, for the most
> part, fully exposed.

Don't know if it would suit your needs, but have you looked at sqlite?
(http://sqlite.org)

There is a non-free version (from the same author) that has support for
encrypted databases. (http://www.hwaci.com/sw/sqlite/prosupport.html)

Rgds,
Mark.

"Mark" <markdv@tiscali.nl> wrote in message

> Don't know if it would suit your needs, but have you looked at sqlite?
> (http://sqlite.org)
>
> There is a non-free version (from the same author) that has support for
> encrypted databases. (http://www.hwaci.com/sw/sqlite/prosupport.html)


Very interesting.

Martin wrote:
> > Why else are you posting in a SQL Server group?
>
> To learn about the general topic of database security rather than one
> specific hypothetical example I concocted that is admittedly too narrow.
>
> In general terms, the link I found reveals part of the problem a little.
> The issue will be an important one to consider with computing in the palm of
> your hand. These days databases might find themselves being carried around
> on laptop or palm machines. In the not-too-distant future, terabyte-class
> portable storage might not be too far fetched an idea. Databases are sure
> to go mobile. With this will come serious security issues as the files
> themselves could fall into the wrong hands very easily.
>
> Yet another hypothetical scenario is a travelling salesman having a database
> of clients, notes and general business intelligence on a notebook computer.
> It is more than likely that, today, stealing that data would just take a
> very quick copy of the database file/s. I'd venture to say that most db's
> are not designed to have strong security at the file level. I understand
> why (cpu and system load in managing constant encrypt/decrypt processing)
> but it is disturbing nevertheless.
>
> -Martin

If you want a broader view, you might want comp.databases.theory. I'm
posting from comp.databases BTW.

It comes down to where you build the wall. Preventing access to the
machine would be the first and best line of defense. Protecting the
data within the DB (encrypted fields) is the last line of defense. Some
situations require multiple levels of defense.

Bottom line is that there is no simple solution. If a hacker has access
to the data files, you've already lost some major security battles.

> If you want a broader view, you might want comp.databases.theory. I'm
> posting from comp.databases BTW.

Thanks, I'll browse that NG and might post after studying the matter furter.

-Martin