Security changes in firebird 2.0.

IF YOU GET MESSAGE "cannot attach to password database" TRYING TO START FIREBIRD AFTER UPGRADE FROM 1.5, PLEASE READ ~/upgrade/v2/security_database.txt. WARNING! Firebird security level is still not satisfactory in one serious aspect , therefore carefully read this document before opening port 3050 to "big dirty" net. Very important security problem of firebird, which is still unresolved transmission of badly encrypted passwords (read - clear) across network. Unfort unately, it's impossible to solve this problem without breaking old clients, i.e . user who has set password using new secure way will not be able to attach to t he server with old client. This fact (and plans to upgrade some aspects of API i n next version) lead to decision not to modify way of passwords transmission in firebird 2.0. Fortunately, this problem may be easily solved using any IP-tunnel ing software (like ZeBeDee) to move data to and from firebird server (this is tr ue for both 1.5 and 2.0) and this is recommended way to access your remote fireb ird server across internet. Special attention was paid to the following aspects of security: - none brute-force resistant passwords encryption in security2.fdb; - ability for any remote user (with valid account) to open security2.fdb and read hashes from it (specially interesting in combination with previous poi nt); - inability for user to change his/her own password; - no protection from remote brute-forcing of passwords on the server dir ectly. Lets have a look at the process of user identification in firebird 1.5. DES algorithm is used to hash password twice - first by client, next by server b efore comparison with hash stored in security database. But this sequence become s completely broken when one SYSDBA changes password - client performs hash calc ulation twice and stores resulting hash directly in security database. Therefore hash management is completely client-dependent (or even better to say client-de fined). To be able to use stronger hashes another approach should be used - hash to be stored on the server is always calculated by server side. And such schema already exists in firebird - this is services API. Therefore decision was made to use services API in any client activity related with users management. For to day gsec and isc_user_add(modify, delete) API both use services to access securi ty database (with exception of embedded access to POSIX CS, see below). Now it b ecame quite easy to make any changes to way of passwords hashing - it's always p erformed by server. Should notice, that new gsec successfully works with old fir ebird versions - as long as server supports services, it's not a problem of gsec , how the has will be calculated for security database, it simply asks services to do the work! New hashing algorithm, selected for firebird 2.0, is SHA-1. Data, stored in PASSWORD field of security database, contains two parts - some random number , used as salt for calculating this particular hash, and hash itself (it's calcu lated as SHA1 (salt || username || password)). This method leads to the facts th at (first) hash valid for user A is invalid for user B and (second) when user ch anges his password even to absolutely the same as later, new data is stored in P ASSWORD field of security2.fdb. This facts don't increase resistance to any atte mpt to brute-force password, but make "visual" analysis of stolen password datab ase much harder. One of the problems, solved during security review, was old gsec. Certai nly, no one can change data in security database without correct password knowle dge, but it's relatively easy to use old version of gsec. It will write bad old hash in PASSWORD field, and if LegacyHash parameter of firebird.conf is set to 0 (this is default, 1 should be used only during upgrade process), login to serve r becomes impossible. Therefore special measures were taken to make remote conne ction to security database impossible at all. Don't be surprised if some old pro

gram, trying to use such direct access, fails - this is by design, only services API (and isc_user_* API functions, in turn using services internally) may be us ed now to access users info. Structure of security database was changed. In general, now it contains patch by Ivan Prenosil, enabling any user to change his/her own password. But th ere are also some small differences. In firebird 1.5 table USERS had to be reada ble by PUBLIC - it was engines requirement, otherwise process of password valida tion failed. In Ivan's patch solution with view, having condition USER = '' in w here clause, was used. That worked due to another bug in engine, which left USER SQL variable empty, not 'authenticator', as it might seem from engine's code. A fter fixing that bug, it was certainly possible to add condition USER = 'authent icator', which in short-term was OK, because normal username is always converted to upper case. But better solution was found, and now user authentication proce ss does not depend from such tricks. As the result - non-SYSDBA user can see onl y his login in any user-management tool (gsec, any GUI, which uses services API) . SYSDBA certainly has full access to manage users' accounts. The chance left for hacker to break firebird installation is trying to b rute-force password. Taking into account, that maximum password length is 8 byte s, this is a bit possible for firebird. Version 2.0 has protection from it - aft er too many attempts to enter wrong password authentication process is locked fo r a while, minimizing the chance of finding correct password during reasonable t ime. POSIX classic server. For some technical and historical reasons, this kind of installation is specially dangerous from security point of view. Users, having embedded access t o databases, MUST be given at least read access to such critical place as securi ty database. This is the main reason that no matter of the fact that in firebird 2 security database is protected from any remote access, use of enhanced passwo rd hashes in it was really required step. Imagine malicious user, having user-le vel access to firebird. He can easily steal security database, take it home and quietly brute-force old DES hashes! After it he can change data in critical data bases, stored on that server - specially dangerous kind of attack. In firebird 2 such activity was made much harder to perform. But embedded POSIX server has one more problem with security - services API on it uses that same command line gsec, as normal users do. Therefore this u tility must have full access to security database. Luckily, the main reason to r estrict direct access to security database was protecting from use of old versio ns of client software. But it's quite unlikely to have old client and new server on the production box. Therefore current solution of giving full embedded acces s to local security database in embedded mode is not too dangerous.