A very Important question, Firebird local security , is it possible?

[hassanein issa]

Hello,

I can not let my end user access the database metadata, this may breach my software secrets exposing my many months of hard work to the public.

How to secure the database file locally and prevent the end-user from accessing directly the database metadata?

Any end user can easily access the firebird metadata by uninstalling the current server and reinstalling a new one with the default (masterkey) password replacing the security database file ( security3.fdb  or security4.fdb) by a fresh new file.

Can we prevent this major security weakness by any means other than Encryption?

Why not the firebird Developers secure and lock the database File and  hash the  Password within the database file itself so that it can not be opened only when re-entering the exact same password?

For me this is the ONLY weakness of firebird, and keeping this security hole making MS Access (the modern versions)  more secure than Firebird! no firebird lover can accept it , is int' it?

thank you very much.

Regards,

[Mark Rotteveel]

On 24-04-2022 21:11, hassanein issa wrote:
> I can not let my end user access the database metadata, this may breach
> my software secrets exposing my many months of hard work to the public.
>

> How to secure the database file _*locally *_and prevent the end-user

> from accessing directly the database metadata?

If you don't trust your end-users, then you shouldn't share the database
with them, but instead offer your application as a remote service (e.g.
SaaS, or a REST API, etc.).

Also, consider whether your secrets are actually that important. And
remember that your code itself is covered by copyright law, so
law-abiding users will not steal your code, and otherwise, see my
previous point.

> Any end user can _*easily *_access the firebird metadata by uninstalling

> the current server and reinstalling a new one with the default
> (masterkey) password replacing the security database file (
> security3.fdb  or security4.fdb) by a fresh new file.
>

> Can we prevent this major security weakness by any means /*other than
> Encryption*/?

No, though if your problem is specifically with protecting PSQL code,
then you can set the source columns to null for functions, procedures
and triggers. However, your PSQL code can then still - with some effort
- be reverse engineered from the BLR.

> Why not the firebird Developers secure and lock the database File and
> hash the  Password within the database file itself so that it can not be
> opened only when re-entering the exact same password?

Among other reasons, Firebird is not designed for paranoid use cases,
and it is also intended as a full-fledged database management system,
where embedded access is just an add-on feature.

> For me this is the /*ONLY */weakness of firebird, and keeping this

> security hole making MS Access (the modern versions)  more secure than
> Firebird! no firebird lover can accept it , is int' it?

I have a surprise for you: opening password protected Access databases
without a password is not impossible.

Mark
--
Mark Rotteveel

[Mathias Pannier (unitel)]

Maybe this will help: https://www.firebirdfaq.org/faq32/

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/7c0c05d2-e54c-461d-9245-3518380c6c80n%40googlegroups.com.

ub.unitel GmbH, Schulstraße 16, 06792 Sandersdorf-Brehna
Geschaeftsfuehrung Klaus Richter, Olaf Meyer
Amtsgericht Stendal
HRB 26389 FA Bitterfeld Steuernr. 116/107/08597 Ust.identNr. DE815796778
Deutsche Bank IBAN DE53 86070024 0 6143234 00
Kreissparkasse Anhalt-Bitterfeld IBAN DE69 80053722 0 3050326 82
_____________________________________________________________________
Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
äußerung ist die des Autors und stellt nicht notwendigerweise die
Ansicht oder Meinung von ub.unitel GmbH dar.
Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich
erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
_____________________________________________________________________

[Dimitry Sibiryakov]

hassanein issa wrote 24.04.2022 21:11:
> Can we prevent this major security weakness by any means other than Encryption?

Bad news for you: even encryption cannot do it for an active (working)
database because to use the database it must be decrypted first.

--
WBR, SD.

[Elmar Haneke]

> Why not the firebird Developers secure and lock the database File and 
> hash the  Password within the database file itself so that it can not
> be opened only when re-entering the exact same password?

That does not prevent your "end-user" from compiling an patched firebird
ignoring that hashed password.

> For me this is the /*ONLY */weakness of firebird, and keeping this

> security hole making MS Access (the modern versions)  more secure than
> Firebird! no firebird lover can accept it , is int' it?

This is an "advantage" of closed source software: It is much more work
to remove such checks from an binary.

BTW: Your application has to tell the password to database engine at a
known API address - "end-user" can get it there in any case.

Encrypting database and hiding key within your application is all you
can do - even what MS access does is not more than an key hidden in
application (in difference data is not encrypted but opening database is
cancelled).

Alternatively you can modify firebird lib to use an different ODS
version and rename API exports of your DLL. This would prevent opening
file with standard tools.

Elmar

[pablo sanchez]

On 4/24/22 16:11, hassanein issa wrote:
I guess, if you use firebird v3 or v4, you can config an alias in
databases.conf, and you can config the users into de same db .

Of course, you have to run a firebird server (no local access).

Regards

> Hello,
> I can not let my end user access the database metadata, this may breach
> my software secrets exposing my many months of hard work to the public.
>

> How to secure the database file _*locally *_and prevent the end-user

> from accessing directly the database metadata?
>

> Any end user can _*easily *_access the firebird metadata by uninstalling

> the current server and reinstalling a new one with the default
> (masterkey) password replacing the security database file (
> security3.fdb  or security4.fdb) by a fresh new file.
>

> Can we prevent this major security weakness by any means /*other than
> Encryption*/?

>
> Why not the firebird Developers secure and lock the database File and
> hash the  Password within the database file itself so that it can not be
> opened only when re-entering the exact same password?
>

> For me this is the /*ONLY */weakness of firebird, and keeping this

> security hole making MS Access (the modern versions)  more secure than
> Firebird! no firebird lover can accept it , is int' it?
>
> thank you very much.
> Regards,
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "firebird-support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to firebird-suppo...@googlegroups.com

> <mailto:firebird-suppo...@googlegroups.com>.

> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/firebird-support/7c0c05d2-e54c-461d-9245-3518380c6c80n%40googlegroups.com

> <https://groups.google.com/d/msgid/firebird-support/7c0c05d2-e54c-461d-9245-3518380c6c80n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[hassanein issa]

Why the firebird developers  don't simply  embed the hased password right into the database file itself which is the same as in the interbase.

By this way we secure the metadata with the data in a simple way, remember our goal is to secure our data from the ordinary or usual user not from the experienced hacke so no needs to sophosticated encryption.

[Alexey Kovyazin]

 Hello,

did I miss some email in this thread where it is explained why encryption cannot be used in the scenario which exactly fits to the encryption?

Regards,

Alexey Kovyazin

IBSurgeon

пн, 25 апр. 2022 г., 11:29 Mathias Pannier (unitel) <pan...@ubsysteme.de>:

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/c559a51681b240e0ae123b877d2c56ef%40NT-Server11.unitel.lokal.

[Dimitry Sibiryakov]

Alexey Kovyazin wrote 26.04.2022 13:24:
> did I miss some email in this thread where it is explained why encryption cannot
> be used in the scenario which exactly fits to the encryption?

Isn't it obvious that for working with an encrypted database the data, crypt
algorithm and crypt key must be met together in a single place creating an
vulnerability point?..
Encryption is good for protecting "cold" data in a scrapped HDD on a stolen
laptop but not quite so in hot cases.

--
WBR, SD.

[Mark Rotteveel]

On 26-04-2022 13:24, Alexey Kovyazin wrote:
> did I miss some email in this thread where it is explained why
> encryption cannot be used in the scenario which exactly fits to the
> encryption?

The OP explicitly excludes encryption as an option, but doesn't give a
reason. However, even if it were not excluded, using encryption doesn't
help: it would still be vulnerable. The scenario of the OP seems to
indicate either use of embedded or a local Firebird install. The key
needs to be available to decrypt the database on that local system
(either at rest, or through some activation service or other means), and
a sufficiently motivated user will be able to obtain the key to decrypt
the database.

Mark
--
Mark Rotteveel

[Alexey Kovyazin]

Hello,

I would like to get more details from OP first before going into this discussion :)

Of course, protection is always balancing between cost of protection and cost of data. If data is really expensive, the vendor can consider hardware keys and other methods.

However, I doubt this is the case, since the initial request seems to be to get something to protect from regular users without great motivation.

Regards,

Alexey Kovyazin

IBSurgeon

вт, 26 апр. 2022 г. в 14:35, Mark Rotteveel <ma...@lawinegevaar.nl>:

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/7e3fe661-753b-47ae-d47e-ce392afed210%40lawinegevaar.nl.

[Elmar Haneke]

Am 26.04.22 um 13:35 schrieb Mark Rotteveel:

> did I miss some email in this thread where it is explained why
> encryption cannot be used in the scenario which exactly fits to the
> encryption?
>
> The OP explicitly excludes encryption as an option, but doesn't give a
> reason.

He did answer that question indirectly in his post from yesterday:

"remember our goal is to secure our data from the ordinary or usual user
not from the experienced hacke so no needs to sophosticated encryption"

Encryption is an to complicated solution to his wishes, he just wants to
insert an magic password into database to protect it.

[Elmar Haneke]

Am 25.04.22 um 22:13 schrieb hassanein issa:

> Why the firebird developers  don't simply  embed the hased password
> right into the database file itself which is the same as in the
> interbase.
> By this way we secure the metadata with the data in a simple way,
> remember our goal is to secure our data from the ordinary or usual
> user not from the experienced hacke so no needs to sophosticated
> encryption.

You would find an simple solution how to circumvent that in google-index
once such an Feature is implemented.

Perhaps it is sufficient for you to hide from your users what embedded
database is used, e.g. by renaming the fbclient.dll and giving some non
descriptive / misleading extension (as .DAT .data .powerDB or ".mdb") to
the database file.


Elmar

[hassanein issa]

Hi All,

My request is very simple, we develop and maintain Medical Patients Records Programs for Doctors in Clinics in general, we was using password Encrypted MS Access (edition of Access 2010 which use SHA1 Hashing which provide enough security against  illegal opening of our database file by an ordinary or medium level person (or hacker!) and want to move to a real robust SQL DB solution, By the Law and as a must provided feature required by our users the database Must provide a decent security locking against illegal opening by unauthorized persons to protect both the Doctors and Patients private data. So we just want to password lock our database file (At database File Level) from unauthorized direct access.

Firebird DB despite all of its wonderful features does not give us this simple security feature! Any ordinary intelligent person can access any local firebird DB File after simple effort! that is very sham!

We just want a locking mechanism at DB File level to prevent ordinary user from access to Firebird DB file using any present DB access programs or tools.

Nowadays, Developers are required and many times forced by Law to build secure apps (both locally secure and online), it is useless to make firebird a rock solid in online security and very vulnerable against simple direct local attack! this is not right.

In clinics, the server can not be locally secure all times , clinics are not a law-enforcement agencies as we know, so any person may steal a *.FDB copy and go home and with little googling he/she can access it by installing new Firebird server and .... etc.

In Access 2010, the password SHA-1 hashing is far enough, for a STRONG password, a  hacker require many months or even few years to access the *.accdb file provide he/she use high cost and fast computer.

Firebird Does not provide this simple local security.

I think this is a Must to have feature that may be implemented in the next firebird versions, i hope.

Thanks.

[Dimitry Sibiryakov]

hassanein issa wrote 12.06.2022 13:30:
> By the Law and as a must provided feature required by our users the database
> Must provide a decent security locking against illegal opening by unauthorized
> persons to protect both the Doctors and Patients private data. So we just want
> to password lock our database file (At database File Level) from unauthorized
> direct access.

Just encrypt the sensitive data before putting it into the database. It is
much more robust solution and many interesting options (including biometric
scanners) are available.

--
WBR, SD.

[fernande...@gmail.com]

You can use

 

https://ib-aid.com/en/firebird-encryption-plugin-framework/

--

You received this message because you are subscribed to the Google Groups "firebird-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/eb4efc9b-ca37-4b80-a5dc-4923949adf00n%40googlegroups.com.

[Alexey Kovyazin]

Hello,

Even if you will convince FB developers to implement such "security theater" password to the Firebird database, any person can download IBFirstAID recovery tool, open database as a corrupted, and view data of tables in Preview tab.

The same is for every database engine - recovery tools bypass security mechanism, so the encryption is the only way to protect data from unauthorised local access of the ordinary person with google in hand.

Can I ask why the database-level encryption is out of the scope of possible solutions you are looking at?

Regards,

Alexey Kovyazin

IBSurgeon

Almaty, Kazakhstan

воскресенье, 12 июня 2022 г. в 14:30:32 UTC+3, conh...@gmail.com:

[Marcelo R. Rodrigues]

i have find a "one way' solution

create a trigger on connect database, as SYSDBA, that way it kill its own access.

alternatively u can create a "permission table" to retrieve a list of permitted users.

sry for my english ins't good.

its important create ur own user with all rights before this, otherwise u risk loss of database access forever.

CREATE TRIGGER TR_LOG_CONNECT
ACTIVE ON CONNECT POSITION 0
AS
BEGIN
  IF USERNAME <> 'MYAUTHORIZEDUSER' THEN
    DELETE FROM MON$ATTACHMENTS where
      MON$USER <> ' MYAUTHORIZEDUSER  ';                          
END;

[Karol Bieniaszewski]

You can restore database with deactivated on connnect triggers, so you do not risk loss of database access forever 😉

And this simply is not the solutions as you see.

 

Regards,

Karol Bieniaszewski

--

You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/39991b4c-d7da-4c01-85cb-42e6cc8afbd8n%40googlegroups.com.

 

[Dimitry Sibiryakov]

Marcelo R. Rodrigues wrote 02.01.2023 18:55:
> its important create ur own user with all rights before this, otherwise u risk
> loss of database access forever.

Try embedded mode: "isql mydatabase -u sysdba -nodbtriggers". You'll be
surprised.

--
WBR, SD.