I want to backup my encrypted database (database level not column level) with this command:
gbak myDb.IB myDb.bak -b -user sysdba -pass masterkey -encrypt mySep -sep myseppass -service service_mgr
But it doesn't work. Here is the error message: gbak: ERROR: encryption mySep is not password-protected
What is the problem?
I have created an encrypted database with Interbase with these commands:
alter database set system encryption password 'myseppass' external;
CREATE ENCRYPTION mySep FOR DES WITH LENGTH 56 BITS FOR DES WITH LENGTH 56 BITS password system encryption password INIT_VECTOR RANDOM;
GRANT encrypt on encryption mySep to SYSDBA;
With IBConsole, i can connect to the database, and in the properties, i see that it is encrypted.
Thank you for reading.
Finally, i was successful with the interbase encryption with interbase XE.
Here are the main parts of the script to encrypt a DB, make an encypted backup and restore it also encrypted.
The database must be created with the embedded user authentication (EUA) enabled.
// connected with SYSDSO: prepare keys and grants
ALTER DATABASE SET SYSTEM ENCRYPTION sepPass;
CREATE ENCRYPTION dbKey FOR DES with LENGTH 56 BITS INIT_VECTOR RANDOM;
CREATE ENCRYPTION backupKey FOR DES with LENGTH 56 BITS password backupKeyPass;
GRANT ENCRYPT ON ENCRYPTION dbKey to SYSDBA;
GRANT ENCRYPT ON ENCRYPTION backupKey to SYSDBA;
// connected with SYSDBA: encrypt database
ALTER DATABASE ENCRYPT WITH dbKey;
// To backup and restore db with gbak
Backup:
gbak -b -v EMPLOYEE.IB EMPLOYEE.IBAK -user SYSDBA -pas masterkey -sep sepPass -encrypt backupKey -se service_mgr
Restore:
gbak -r -v EMPLOYEE.IBAK EMPLOYEE.IB -user SYSDBA -pas masterkey -sep sepPass -decrypt backupKeyPass -se service_mgr
Related
I am working with InterBase 2020 version. Since InterBase installs with default user SYSDBA and default password for SYSDBA as masterkey , I want to change the password for SYSDBA user.
Using gsec tool I am able to change the password however when I backup the database and restore it on different machine having SYSDBA password as masterkey , I am able to do this successfully.
So even if I have changed the password on my machine , InterBase db backup (with changed SYSDBA password) could be restored on a machine having SYSDBA password as masterkey.
Where is the security in this case and How could I prevent this ?
Is Embedded User Authentication a solution to prevent unauthorized users restoring the database ?
You have to activate Embedded User Authentication in your Database. So you can define different SYSDBA per Database with different password.
I have a Firebird application which gives the Firebird error Transactions count exceeded.
How can we fix this error?
The full error message of this error is "Implementation Limit Exceeded - Transactions count exceeded. Perform a backup and restore to make the database operable again". And as that error suggests, you need to backup and then restore your database.
In Firebird 2.5 and lower, the maximum number of transactions is (near) 231 - 1, for Firebird 3 and higher it is 248. Once this limit is reached, the database is for all intents and purposes read-only.
To reset the transaction count, you need to backup the database using gbak, and restore it using the proper database owner user (or possibly SYSDBA). To do this you need to perform the following steps:
Mark database explicitly read-only with gfix using SYSDBA or the database owner user:
gfix -user <user> -password <password> -mode read_only <databasename>
This is necessary because gbak needs to start a transaction, and in read_write mode that is not possible anymore (in read_only mode, transactions will 'reuse' the last committed transaction for read-only operations).
Backup your database with gbak using SYSDBA or the database owner user:
gbak -user <user> -password <password> -backup <databasename> <backupfilename>
Rename your existing database file <databasename> to something else for safekeeping. You can delete it after you have verified the restore went fine and the new database is usable.
Restore the database with the appropriate user that should be the database owner:
gbak -user <user> -password <password> -create <backupfilename> <databasename>
Mark database as writable again with gfix using SYSDBA or the database owner user:
gfix -user <user> -password <password> -mode read_write <databasename>
Is it possible to create a user in PostgreSQL without providing the plain text password (ideally, I would like to be able to create a user providing only its password crypted with sha-256) ?
What I would like to do is to create a user with something like that :
CREATE USER "martin" WITH PASSWORD '$6$kH3l2bj8iT$KKrTAKDF4OoE7w.oy(...)BPwcTBN/V42hqE.';
Is there some way to do that ?
Thank you for your help.
You may provide the password already hashed with md5, as said in the doc (CREATE ROLE):
ENCRYPTED UNENCRYPTED These key words control whether the password is
stored encrypted in the system catalogs. (If neither is specified, the
default behavior is determined by the configuration parameter
password_encryption.) If the presented password string is already in
MD5-encrypted format, then it is stored encrypted as-is, regardless of
whether ENCRYPTED or UNENCRYPTED is specified (since the system cannot
decrypt the specified encrypted password string). This allows
reloading of encrypted passwords during dump/restore.
The information that's missing here is that the MD5-encrypted string should be the password concatened with the username, plus md5 at the beginning.
So for example to create u0 with the password foobar, knowing that md5('foobaru0') is ac4bbe016b808c3c0b816981f240dcae:
CREATE USER u0 PASSWORD 'md5ac4bbe016b808c3c0b816981f240dcae';
and then u0 will be able to log in by typing foobar as the password.
I don't think that there's currently a way to use SHA-256 instead of md5 for PostgreSQL passwords.
I'm not aware of a way to override the default md5 encryption of passwords, but if you have a ROLE (aka "USER") that has an already md5-encrypted password it appears that you can supply that. Verify this using pg_dumpall -g (to see the globals from the cluster)
Eg.
psql postgres
create role foo with encrypted password foobar;
\q
-- View the role from pg_dumpall -g
pg_dumpall -g | grep foo
CREATE ROLE foo;
ALTER ROLE foo WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION PASSWORD 'md5c98cbfeb6a347a47eb8e96cfb4c4b890';
Or get it from:
select * from pg_catalog.pg_shadow;
-- create the role again with the already-encrypted password
psql postgres
drop role foo;
CREATE ROLE foo;
ALTER ROLE foo WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION PASSWORD 'md5c98cbfeb6a347a47eb8e96cfb4c4b890';
\q
-- view the ROLE with the same password
pg_dumpall -g | grep foo
CREATE ROLE foo;
ALTER ROLE foo WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION PASSWORD 'md5c98cbfeb6a347a47eb8e96cfb4c4b890';
Docs for CREATE ROLE
At least from version 10.10, it's possible to use SCRAM-SHA-256 as well.
CREATE USER user_name
WITH PASSWORD 'SCRAM-SHA-256$4096:UunGvPETiX/JNGBvjOgW9A==$CPGNh7/MRfs0ispH9/HSJajOI8Uhp+UCRo/b/ToXIEY=:L6NzxQ3XUeWEeRa+oiuajC9Vgl7wk6ZpHAHl+pv4m00=';
GRANT CONNECT ON DATABASE database_name TO user_name;
(It's important not to forget to GRANT privileges to the new user)
If you want SCRAM to be used by default, you can set the password_cryptography to SCRAM-SHA-256:
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
SELECT pg_reload_conf();
I know it's possible to set the passwords also avoiding SQL statements, this link to the documentation should help. Maybe, this is a bit less verbose.
Anyway, md5 should be avoided when possible, SCRAM is a more robust way to store passwords.
In case you cannot find a way to create the SCRAM string accepted by Postgres, you can let it crate one for you with the following code.
Remember to set the password_encryption to SCRAM
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
SELECT pg_reload_conf();
This cannot be run in a transaction block. If for instance, you're using migration files, you probably have to create two different files just ofr those two commands.
Create a user with the password you need to encode.
CREATE USER tmp_user_to_create_a_password
WITH PASSWORD 'your_password';
Read the password with SCRAM encryption.
SELECT rolpassword
FROM pg_catalog.pg_authid
WHERE rolname='tmp_user_to_create_a_password';
Drop the user
DROP USER IF EXISTS tmp_user_to_create_a_password;
Now you can create your user without using plain text.
CREATE USER user_name
WITH PASSWORD 'SCRAM-SHA-256$4096:3Lctb6GmH15cSO4bjcDsXg==$BSuI1c10J+NZ/Wmx4hwP4TvpdKEO9rl2hekZ8/DVuyA=:j8G9NJ30Xbz3Za2mjXF/j6O3DJbWyqvX886haFe4aCs=';
GRANT CONNECT ON DATABASE database_name TO user_name;
You can now use 'user_name' and 'your_password' to log-in.
Much easier way to to this is:
CREATE USER u0 PASSWORD 'foobar';
select * from pg_catalog.pg_shadow;
Gives passwd: md5ac4bbe016b808c3c0b816981f240dcae
When executing this postgres command:
EXECUTE 'CREATE USER myuser WITH UNENCRYPTED PASSWORD ''my+password''';
I see the error:
RoundhousE encountered an error.
Npgsql.PostgresException (0x80004005): 0A000: UNENCRYPTED PASSWORD is no longer supported
Is there a workaround for this, or will the password need to be manually encrypted and supplied without the UNENCRYPTED keyword?
No. All you have to do is to omit the UNENCRYPTED.
You can supply both encrypted and unencrypted passwords that way, and PostgreSQL can tell the difference automatically.
PostgreSQL 10+ no longer support user creation with UNENCRYPTED password,
create it with ENCRYPTED:
CREATE USER myuser WITH ENCRYPTED PASSWORD ''my+password''
I need to clone role from one postgresql database to another. Is it possible to somehow extract role password hash and set it in another database ? I'd like to avoid any clear password manipulation...
If PostgreSQL thinks you're setting the password with an MD5 hash, it stores it directly. From the docs
If the presented password string is already in MD5-encrypted format, then it is stored encrypted as-is, regardless of whether ENCRYPTED or UNENCRYPTED is specified (since the system cannot decrypt the specified encrypted password string). This allows reloading of encrypted passwords during dump/restore.
you can select password from pg_shadow and use it as per docs, as Eavn told. Or you can use pg_dumpall -g which will basically prepare statements to run with md5 passwords eg. at my machine:
CREATE ROLE r;
ALTER ROLE r WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION NOBYPASSRLS PASSWORD 'md5514f1b439f404f86f77090fa9edc96ce';