Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database encryption [CORE657] #1023

Closed
firebird-automations opened this issue Sep 17, 2003 · 18 comments
Closed

Database encryption [CORE657] #1023

firebird-automations opened this issue Sep 17, 2003 · 18 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pcisar

Relate to CORE1913
Is duplicated by CORE3783
Is duplicated by CORE3861
Relate to CORE2405

Votes: 27

SFID: 807965#⁠
Submitted By: pcisar

Allow for database to be encrypted -- user
defined/selectable library/parameters.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-12-02 16:24
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

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

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

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Component: Security [ 10071 ]

assignee: Vlad Horsun [ hvlad ]

SF_ID: 807965 =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

SF_ID: 807965 =>

@firebird-automations
Copy link
Collaborator Author

Commented by: Mercea Paul (m24paul)

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: Dejan Schild (schild)

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).

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10681 ] => Firebird [ 15055 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE1913 [ CORE1913 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Yiannis Bourkelis (yiannis)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

>>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?

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE3783 [ CORE3783 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue is duplicated by CORE3861 [ CORE3861 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ] => Alexander Peshkov [ alexpeshkoff ]

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Mike (fibitoll)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE2405 [ CORE2405 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants