pt_wico wrote:

>Hi All
>I've several qs on fb db security
>
>1) Is this case possible? if I created an fdb file and then somebody
>take that file and open and manipulate using their own sysdba
>account. How to prevent this?
>

I think currently the only way is to encrypt data by using key,
and your app should pass it by viewing data.
Idea is simple :
TABLE T1, with row A1.
row A1 is encrypted.
App must pass key to , for example procedure P_VIEW_T1
it would be select * from P_VIEW_T1(:MyKey).

However, this would easily hacked by using any db monitor to catch key.
More reliable way is to pass Key which is valid only for that
current_transaction + plus signed in hidden methods (prcodures metadata
is deleted).
Sequence would be :
Create Connection, Get current_transaction, current_connection
Create Key
Pass it to temporal table (NO commit !)
Ask For data
Stored proc : see for current_transaction, curretn_connection, create
Key according to values.
Look for same key in temporal table, if no exists, failure.
Retrieve data.

For example
My cur_con = 12 , cur_trans = 8099
I am creating key with salt : 12-8099-MySalt ----- Hashing MD5 --->
XXXXX.XXXX1
Passing it to temporal table.
Doing select * from P_VIEW_T1
P_VIEW_T1 knows my transaction, connection, , and there must be encoded
MySalt to, so it creates Key 12-8099-MySalt --->Hashes MD5 --> XXXX.XXXX1
Looks up in temporal table for matches, if found, ok, if no, failure.
After disconnect, temporal key is desctructed, because no commit has
been done.

So hacker to hack data, should create connection, transaction with same
number, reverse engineer from BLR MySalt, Reverse engineer key creation
engine, and reverse engineer Enryption mechanism, this quite long way to
get data , So the more key creation engine and encryption engine is
difficult, the more is harder to crack data.
I think, that such mechanism would stop most curious people about
viewing sensitive data, despite, they get access to file.