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-issue-importer opened this issue Sep 17, 2003 · 18 comments
Closed

Database encryption [CORE657] #1023

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

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 14, 2006

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-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 1, 2006

Modified by: @dyemanov

Component: Security [ 10071 ]

assignee: Vlad Horsun [ hvlad ]

SF_ID: 807965 =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jul 11, 2006

Modified by: @dyemanov

Fix Version: 3.0 [ 10048 ]

SF_ID: 807965 =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 1, 2007

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-issue-importer
Copy link
Author

firebird-issue-importer commented Oct 17, 2007

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-issue-importer
Copy link
Author

firebird-issue-importer commented Nov 16, 2007

Modified by: @dyemanov

Fix Version: 3.0.0 [ 10048 ] =>

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jan 28, 2008

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented May 26, 2008

Modified by: @dyemanov

Link: This issue relate to CORE1913 [ CORE1913 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Mar 2, 2011

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-issue-importer
Copy link
Author

firebird-issue-importer commented Dec 8, 2011

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-issue-importer
Copy link
Author

firebird-issue-importer commented Mar 5, 2012

Modified by: @dyemanov

Link: This issue is duplicated by CORE3783 [ CORE3783 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented May 31, 2012

Modified by: Sean Leyne (seanleyne)

Link: This issue is duplicated by CORE3861 [ CORE3861 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Jun 1, 2012

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-issue-importer
Copy link
Author

firebird-issue-importer commented Oct 16, 2013

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-issue-importer
Copy link
Author

firebird-issue-importer commented Apr 24, 2014

Modified by: @dyemanov

Link: This issue relate to CORE2405 [ CORE2405 ]

@firebird-issue-importer
Copy link
Author

firebird-issue-importer commented Sep 22, 2015

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