open any database with its own server sysdba account.

[Midsoft UK]

Hello

We have just noticed that if we set up a new FireBird 3 server and copy an existing database file to it, then you can open the DB using the sysdba and password form the new server instead of the one contained in the database.

In fact if you open it in embedded mode you don't even need a password.

Is there something we can do turn prevent this as it seems like a huge security hole?

Thanks

Andy

[Tomasz Tyrakowski]

When someone gains a direct access to the database file (i.e. is able to
physically copy it to another device), only a complete DB encryption
would protect the data inside from accessing it (and FB doesn't do that
AFAIK).
FB assumes that if you have OS-level access to the DB file, you're as
good as SYSDBA.
Perhaps other experienced FB users can provide more rationale, but for
me this argument is convincing enough.

cheers
Tomasz

________________________________


Ta wiadomość zawiera poufne informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

[Dimitry Sibiryakov]

18.03.2021 14:51, Midsoft UK wrote:
> Is there something we can do turn prevent this as it seems like a huge security hole?

Do not let anybody have access to the database file.

And no, encryption won't help in this case as well. It is only able to protect data
from recovery from HDD dropped into a trash bin.

--
WBR, SD.

[Mark Rotteveel]

If the key is not obviously accessible on the server (as in: it is not
on the local filesystem), then encryption will help against the casual
database 'thief'. Only a determined thief (e.g. one that will lift the
key out of server memory), or a setup where the key is on the
filesystem, won't protect against this scenario.

Mark

[Mark Rotteveel]

No, the potential security hole is that people have sufficient access to
copy your Firebird database to another system. Ignoring options like
database encryption, this applies to all database systems, not just
Firebird: if you have access to the database file(s) or access to the
backups, and are able to transfer them to a database system install
under your control, then you'll have full access to the data.

The only protection against such a scenario is using database encryption
(support exists in Firebird 3, but requires a third-party plugin for
actual encryption), but then you need to ensure that only authorized
people have access to the key, which essentially just moves the problem.

In other words, the behaviour you describe is expected and how it is
supposed to work. The real protection is sufficient access control to
the database file and backups.

Mark

[Midsoft UK]

"Do not let anybody have access to the database file."

unfortunately that's impossible.

Our situation is - we have thousands of installations, many with 2 and 3 user peer to peer networks. We cannot prevent a user knows and has access to their file system, taking the database file and copying to a different server.  If it was possible to use an external tool to encrypt the database then that would work for us.
Andy

[Carlos H. Cantu]

The IBSurgeon Encryption plugin allows the key to be sent by the client application. This can solve your problem, if you take enough precaution to avoid a hacker to be able to disassembly the application code and get the key from there.

FYI:
https://ib-aid.com/en/news/new-article-how-firebird-database-encryption-works/

[]s
Carlos
www.firebirdnews.org - www.FireBase.com.br

-- 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/78a731eb-80cd-4a48-a3da-2735179250ean%40googlegroups.com.

[Dimitry Sibiryakov]

18.03.2021 15:59, Carlos H. Cantu wrote:
> The IBSurgeon Encryption plugin allows the key to be sent by the client application. This
> can solve your problem, if you take enough precaution to avoid a hacker to be able to
> disassembly the application code and get the key from there.

IBPhoenix also has it: https://www.ibphoenix.com/products/software/encryptionplugin

--
WBR, SD.

[Dimitry Sibiryakov]

18.03.2021 15:41, Midsoft UK wrote:
> Our situation is - we have thousands of installations, many with 2 and 3 user peer to peer
> networks.

In this case it is their databases with their data inside and its security is their
problem, not yours.

--
WBR, SD.

[Dalton Calford]

In earlier versions of Firebird, you could create a role with the name SYSDBA - preventing sysdba from logging in.   Obviously, this means you would need to have a user with all the rights of SYSDBA to use for maintenance.

I don't know if this is still possible.

regards

Dalton

--
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/51a55006-7bdb-7c32-6cd7-2f4988243ac4%40ibphoenix.com.

[Mark Rotteveel]

On 18-03-2021 15:41, Midsoft UK wrote:
> "Do not let anybody have access to the database file."
>
> unfortunately that's impossible.
>
> Our situation is - we have thousands of installations, many with 2 and 3
> user peer to peer networks. We cannot prevent a user knows and has
> access to their file system, taking the database file and copying to a
> different server.  If it was possible to use an external tool to encrypt
> the database then that would work for us.

You don't need an external tool, you need Firebird 3 and a third-party
database encryption plugin for that. However, that just moves the
problem to one of key management: your users will need to have the key
in one form or another to be able to access the database, so if they
have and access to the database file and the key, they can still do what
they want.

Mark
--
Mark Rotteveel

[Carlos H. Cantu]

The role trick was always a "fake" security, since it was very easy to open the database file in an hex editor and "erase" the role.

Btw, FB 3 doesn't allow such role anymore.

Carlos
www.firebirdnews.org - www.FireBase.com.br

. To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/CANY9GwoSLyPZx6CPALSxrwLbMh9h2hx-unzL_zEryQ7D-1_6Tw%40mail.gmail.com.

[Midsoft UK]

encryption plugin worked perfectly. Our customers would never have the key.

[Ismael L. Donis Garcia]

You can also create a trigger, it is only effective for newbies, but always restricts something.

 

CREATE EXCEPTION E_INCORRECT_USER 'Unauthorized user.';

 

 

SET TERM ^ ;

 

CREATE TRIGGER TR_USER_BC ACTIVE

 

ON CONNECT POSITION 1

 

AS

 

DECLARE VARIABLE INT_TYPE INTEGER;

 

BEGIN

 

  SELECT FIRST 1 u.RDB$USER_TYPE FROM RDB$USER_PRIVILEGES u WHERE u.RDB$USER = CURRENT_USER AND u.RDB$USER <> 'PUBLIC' AND u.RDB$USER <> 'SYSDBA' INTO INT_TYPE;

 

  IF (ROW_COUNT = 0) THEN

 

    EXCEPTION E_INCORRECT_USER;

 

END^

 

SET TERM ; ^

 

Best Regards

--
Ismael
Devuan User: http://distrowatch.com/table.php?distribution=devuan
Web Site: https://gitlab.uic.cu/ismael.donis/sistema-de-contabilidad-general/

--

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/a5de40f5-bf40-4d49-ab78-48310f75d573n%40googlegroups.com.

[pablo sanchez]

On 3/18/21 10:51 AM, Midsoft UK wrote:

From "Migration Guide to Firebird 3.0", AFAIK, you could create and
configure credentials within the same database, so no server credentials
can be used to connect.

I know it's not a drop in, but that should work.

Regards

Pablo

> --
> 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/f311ce4f-1c9d-4aa0-af87-c3be68f2e1f0n%40googlegroups.com
> <https://groups.google.com/d/msgid/firebird-support/f311ce4f-1c9d-4aa0-af87-c3be68f2e1f0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Dimitry Sibiryakov]

18.03.2021 20:38, pablo sanchez wrote:
> I know it's not a drop in, but that should work.

It won't because it is configured in external databases.conf.

--
WBR, SD.

[Carlos H. Cantu]

ps> From "Migration Guide to Firebird 3.0", AFAIK, you could create and
ps> configure credentials within the same database, so no server credentials
ps> can be used to connect.

You can, but it wouldn't help, since anyone could do an embedded
connection to the database as SYSDBA and do whatever they want.

[]s
Carlos
Migration Guide to Firebird 3
http://www.firebirdnews.org/migration-guide-to-firebird-3/

ps> On 3/18/21 10:51 AM, Midsoft UK wrote:

ps> From "Migration Guide to Firebird 3.0", AFAIK, you could create and
ps> configure credentials within the same database, so no server credentials
ps> can be used to connect.

ps> I know it's not a drop in, but that should work.

ps> Regards

ps> Pablo

[Mark Rotteveel]

On 18-03-2021 18:17, Midsoft UK wrote:
> encryption plugin worked perfectly. Our customers would never have the key.

In one way or another, your customers will have the key, otherwise their
Firebird server instance wouldn't be able to decrypt and access the
database.

That is important to keep in mind: if someone is determined, they will
be able to access the key, it might just be hard enough to deter casual
access.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

19.03.2021 12:18, Mark Rotteveel wrote:
> That is important to keep in mind: if someone is determined, they will be able to access
> the key, it might just be hard enough to deter casual access.

It is not even needed to have a key: data can be captured from the application screen.

--
WBR, SD.

[Mark Rotteveel]

Please keep the context of this thread in mind...

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

19.03.2021 12:25, Mark Rotteveel wrote:
> Please keep the context of this thread in mind...

I would but the author didn't explain what exactly scenario he want to be protected
from. If they distributes a database with some data inside and want to limit access to
these data to their application only - encryption won't work. If they want to protect
customer's data from customer's malevolent employee - encryption won't work.

--
WBR, SD.