Implementing Stronger Password Protection

Go Up to Database User Management

Stronger password protection on InterBase databases can be implemented since InterBase XE. This additional functionality supports a longer effective password length, resulting in stronger password protection.

Requirements/Constraints

This design supports server-wide user authentication as manifested by the USERS table of the security database, configured with the IBCONFIG.ADMIN_IB property parameter, which defaults to the admin.ib file.
The design also supports EUA (Embedded User Authentication) databases. As with the non-EUA databases, it also has to be explicitly enabled by the owner/administrator. Please note that the USERS table in admin.ib has RDB$USERS as the counterpart in EUA databases; so the earlier references have to be compatible with EUA database references.
A user account in the USERS table can only accommodate a single password hash value. This restriction means that once the user account password is changed to use SHA-1, the user has to use the new IB client to log into the new IB server.
A plaintext password length of 32 bytes is supported in this release, up from 8 bytes in earlier versions of InterBase.
An updated version of IBConsole is present in the kit. This version does not show the “Default” buttons in the database/server login screens.
A batch script (changepassword.bat) is now provided in the <interbase>/bin directory to update the SYSDBA account password post-install.

Getting Started with Implementing Stronger Password Protection

The DES-CRYPT password algorithm has been replaced with a modern cryptographic hash function that is more widely accepted by organizations in private industry and government. The design uses SHA-1, which generates a fixed length 160-bit hash.

Before starting, it is strongly recommended that you back up your old admin.ib from the current installation before installing the new InterBase. This allows you to restore it, if needed.
After new IB has been installed on the server, run the following against admin.ib:
```
isql admin.ib -user SYSDBA -pass xxxxxxx
sql> ALTER DATABASE SET PASSWORD DIGEST 'SHA-1';
sql> CREATE DOMAIN PASSWORD_DIGEST AS CHAR(16) CHARACTER SET ASCII;
sql> ALTER TABLE USERS ADD PASSWORD_DIGEST PASSWORD_DIGEST;
sql> UPDATE USERS SET PASSWORD_DIGEST = 'DES-CRYPT';
sql> COMMIT; 
```
Note:
The ALTER DATABASE command can only be run by the database owner or SYSDBA. This command modifies RDB$DATABASE.RDB$PASSWORD_DIGEST to the string value "SHA-1". This means that all new password hash generation for new or existing user accounts in the USERS table will use the SHA-1 hash function.

The password hash function can be reset to DES-CRYPT using the same DDL:

 ALTER DATABASE SET PASSWORD DIGEST 'DES-CRYPT';

The admin database is now prepared so that new user accounts or modifying the password of existing accounts will generate SHA-1 password hashes against plaintext passwords up to an untruncated length of 32 significant bytes.

GSEC [add | modify], IBConsole, and the IB Services API support the SHA-1 password hash algorithm. Any of these tools can be used to maintain the passwords of server-wide user accounts. If an existing user account has had its password changed, then that user must log in to the server using the new IB client library.

Important:
There will be backward compatibility problems if the converted admin.ib database is backed up and restored by an older IB engine after the password hashes have been converted to SHA-1. Older IB engines will not understand the different password hashes and will cause unrecoverable login errors.

Advance To:

Enabling Embedded User Authentication

Implementing Stronger Password Protection

Contents

Requirements/Constraints

Getting Started with Implementing Stronger Password Protection

See Also

Advance To: