There are other areas I would like to see worked on before anyone tries
encryption.

Larger Database Object Names (including objects such as users and roles)
Database Schema
Named remote databases (so that you are not building/destroying connections
within the life of a stored procedure)
Security enhancements such as visibility of database objects
The ability to define a database so that the database triggers can NOT be
disabled - which is the only reason I would like database security.

As for security, the current model is not sufficient in many cases. If you
are using OS level authentication, you have no idea if the user is the
intended person or just walked away from their desk. Application enforced
security is easy to bypass so the only way to secure the database is to have
a method of challenge/authenticate the user.

For example, the user says they are 'BOB'. With OS
level authentication you assume they are correct as you get the name from
the OS itself. With Datbase authentication you further request a password.

Instead you should have the user state who they are (you can use user names,
biometric id's, random sequence of numbers - anything) and then have the
database return a challenge question. The challenge question could still
be the user password to keep old processes working, but it could also be
random question from a selection in the database - provided by the user, so
that the answer changes with every login. You can also have partial key
questions, where the user is faced with filling in the missing parts of a
access key.

If the database expects different answers, the brute force method of attack
is stymied.

SYSDBA or $admin role users should also present the access key which gives
the server the key to open the database. The access key opens the one page
with the various access connection rights for the various users. Now you
can use private public keys so that the database server is identified to the
client and vice versa. You can also use ssh to tunnel all over the wire
communication.

The net result is that the database will not open unless it is on the right
server in the right location being connected to via an approved client (all
of this can be done with database triggers).

So, no brute force, public/private key hashes, only certain individuals who
can open/start the database and then all the rest of the credentials are
kept encrypted within the database.

You can even put this encrypted database within a dedicated partition on
linux so that it looks like an unformated drive.

I have only touched the surface as to what the security protocols could be,
all have there benefits and drawbacks. All can be bypassed but the level
of sophistication required makes the task so daunting that only the NSA
would bother.

So, can a measure of security be implemented? Yes.
Is it in my humble opinion a top priority? No
Would I work against someone who is trying to do it? No
Would I send money to aid in the project? Maybe.

At this point, I would send money (Distributel does what it can to support
IBphoenix) for schema and a few other things, but not for security until the
rest of the system is complete.

If people want security in the database, then they can do the work
themselves or send money to those who are willing to.

but this discussion has really been going on a long time and until someone
does the work or pays for it to get done, it will never end.

best regards

Dalton




2010/11/4 Dimitry Sibiryakov <sd@...>

> 04.11.2010 16:19, ettotev wrote:
> > I may be dumb, but it seems to me that a simple encryption plug-in would
> only need three hooks in the embedded engine - one to receive the username
> and password entered by the user and based on them to initialize the
> symmetric encryption key; one to handle the request for page read - read and
> decrypt; and one for page write - encrypt and write to disk. Am I missing so
> much here?
>
> Yep. You are missing simple stubborn fact: though encryption code in
> engine is usable,
> as Dmitry said, nobody comes with any encryption plugin so far. Neither
> open-sourced, nor
> commercial.
>
> --
> SY, SD.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]