|
Date: 2004-08-23 00:36
Sender: brianmoloney Logged In: YES user_id=1108354 This should be a mandatory and selectable feature for any DBMS; not used (mainly for performance reasons) when the envt is secure; used when the DBMS is for a shrink-wrapped product. The availability of this feature should be scheduled and would be a distinguishing factor for many software houses in DBMS choice (i.e. for me, it's the key one missing that makes Firebird a maybe instead of a definite choice for DBMS) It would be the best of all worlds if the encryption were a) selectable (on/off), and b) encryption-level selectable, to give some selectable trade-offs between security and performance, and c) algorithm-selectable Date: 2004-05-05 10:59
Sender: stevecharon Logged In: YES user_id=470099 I recommend this too as this is something a PRO DB should have! This is to have nobody else but the db engine reading the db data. It's not clear for me if I could specify what 'objects' I want to encrypt.
I think for demo database where I want users to see tables and data but I don't want to allow users to see any procedure. It will be available this feature? To encrypt only triggers or procedure? There should be two levels of encryption: data and structure.
Encryption of data could be like Alice suggest. Encryption of structure should prevent end users to see or modify structure of database (DDL), but don't prevent them to see data (DML). There could be file with same name as database (ec. dbname.key) with structure key. If key file exist and key is correct, then user can access to db structure, elsewhere just access to data (do select/update/modify). I would like to choose a table or a column to be encrypted, not everything because of the performance penalty.
The encryption key could be specified in the connectionstring. That way we will not have to change anything else in our applications except of the connectionstring, that is a global variable most of times. >>Dejan Schild
objects and data should be encrypted when storing by providing key but for read data should provide another key (like AES work) but this key should not be stored with database or inside - this is wrong solution if user can steal whole database file what prevent for steal also dbname.key from the same disc? as mentioned in a duplicate issue and imho VERY important,
"In the U.S., the meaningful use rules(for the healthcare industry) now dictates that data encryption has to be an option that can be turned on. And, the encryption algorithm that is acceptable is AES. " So it should be clearly visible for future users that the DB has a important security issue and maybe should not be used without special considerations on these issues. In other words, i think its extremly important to have this encryption feature fore firebird. And yes, i would neet it too, urgendly. The structure of the db as well as the data have to be encrypted. For making it faster, this could be in a 2-Level-fashion(maybe in next Version V4, after first encryption features in V3): Strong costly encryption in first level, when starting the DB, so that a stolen, down db couldn't be used, and a faster decryptable part which with use of the first part is allowing the fast access of the data. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Database encryption
Sender: adnanoncevarlik
Logged In: YES
user_id=1046258
Hi,
I recommend this too (and I need it). Steve Charon has said
truth. If the some one have access rights to DB, he can see
the Data in the FDB file. I think everything in the DB can't
be readable by an user.
Some DB Admins have the access rights to DB but they don't
have permission to read Salary Data or payment Data :)
May be it will be solved with a default UDF's. I want to
write my some data with a encryption function in the
Firebird Standard UDFs.
for example ;
(INSERT example)
INSERT INTO MYTABLE (MYFIELD1, MYFIELD2, MYFIELD3)
VALUES (VALUE1, ENCRYPTNUMERICDATA(VALUE2, ENCRYPTIONVALUE),
ENCRYPTSTRINGDATA(VALUE3, STRINGENCRYPTIONVALUE))
(SELECT example)
SELECT MYFIELD1, DECRYPTNUMERICDATA(MYFIELD2,
NUMERICENCRYPTIONVALUE) MYFIELD2,
DECRYPTSTRINGDATA(MYFIELD3, STRINGENCRYPTIONVALUE) MYFIELD3
FROM MYTABLE
WHERE DECRYPTNUMERICDATA(MYFIELD2, ENCRYPTIONVALUE) >= 3000
May be this way better than the whole database encryption.
Best Regards