Firebird Documentation IndexFirebird 3.0.6 Release NotesCompatibility Issues → Initializing the Security Database
Firebird Home Firebird Home Prev: Embedded ConnectionsFirebird Documentation IndexUp: Compatibility IssuesNext: Legacy Authentication

Initializing the Security Database

Initialization Steps
Additional Notes About Security Databases

By default, Firebird 3 is configured for the new authentication model which uses SRP to work with user passwords and generate unique session identifiers for traffic encryption. The security database (security3.fdb) has no predefined users. This is intentional.

However, when using the standard installers for Windows, Linux and MacOSX, the SYSDBA user is created during the final step of the installation, with a password that is either random or defined via a user input routine.

In a situation where the SYSDBA initialization step either fails, or is missing from an OS-specific install process, such as a Windows .zip kit install or a dedicated POSIX platform port, it may be necessary to initialize the security database manually for use with the SRP plugins. You will need to create the user SYSDBA and set up the password for it using SQL CREATE USER command syntax in embedded mode as your first step to getting access to databases and utilities.

The gsec utility can be used instead but, having been deprecated, it is not discussed here.


This initialization is not required and should NOT be performed if you have configured the server to use legacy (pre-Firebird 3 style) authentication and user management. The legacy security plugins totally preserve the legacy behaviour and thus contain the legacy record for SYSDBA with masterke as the initial password.

Instructions for configuring firebird.conf for legacy authentication behaviour are in the next section.

Initialization Steps

Initialization is performed in embedded mode using the isql utility. For an embedded connection, an authentication password is not required and will be ignored if you provide one. An embedded connection will work fine with no login credentials and log you in using your host credentials if you omit a user name. However, even though the user name is not subject to authentication, creating or modifying anything in the existing security database requires that the user be SYSDBA;  otherwise, isql will throw a privilege error for the CREATE USER request.

The SQL user management commands will work with any open database. Because the sample database employee.fdb is present in your installation and already aliased in databases.conf, it is convenient to use it for the user management task.

  1. Stop the Firebird server.  Firebird 3 caches connections to the security database aggressively. The presence of server connections may prevent isql from establishing an embedded connection.

  2. In a suitable shell, start an isql interactive session, opening the employee database via its alias:

      > isql -user sysdba employee
  3. Create the SYSDBA user:

      SQL> create user SYSDBA password 'SomethingCryptic';
      SQL> commit;
      SQL> quit;


    The SYSDBA user will have full administrator rights automatically. Do not assign the ADMIN role (RDB$ADMIN) to SYSDBA.

    Quick Tip

    From v.3.0.1, the statement CREATE OR ALTER USER SYSDBA PASSWORD <password> can be used to initialize an empty securityN.fdb security database.

  4. To complete the initialization, start the Firebird server again. Now you will be able to perform a network login to databases, including the security database, using the password you assigned to SYSDBA.

About Passwords

  • An effective password, using the default user manager Srp, can be up to 20 characters, although a password of up to 255 characters will be valid.

  • If you intend in future to configure the server to use legacy authentication (not recommended!), then only the first 8 characters of any password, including that of the SYSDBA, will be read.

  • masterkey is NOT a recommended password for SYSDBA!

Additional Notes About Security Databases

Since Firebird 2, users—including SYSDBA—could not log in to the security database directly. With Firebird 3 it is possible to establish a direct, embedded connection to the security database. With the appropriate configuration parameters, you can control the ability to connect remotely to other security databases.

The gsec utility, although deprecated in Firebird 3, is still available for access to security3.fdb only. It cannot be used to manage a custom user database. It is recommended that database admins plan to move away from relying on gsec and become familiar with the newer SQL user management features.

Prev: Embedded ConnectionsFirebird Documentation IndexUp: Compatibility IssuesNext: Legacy Authentication
Firebird Documentation IndexFirebird 3.0.6 Release NotesCompatibility Issues → Initializing the Security Database