Correct some files to refer to FB2 and security2.fdb

builds/install/arch-specific/freebsd/install.sh.in

@@ -31,7 +31,7 @@
 #   Contributor(s):
 #  
 # 
-#   $Id: install.sh.in,v 1.7 2004-04-27 12:35:52 brodsom Exp $
+#   $Id: install.sh.in,v 1.8 2005-03-05 01:43:39 robocop Exp $
 # 
 
 #  Install script for FirebirdSQL database engine
@@ -162,7 +162,7 @@ cp $BuiltFBDir/help/help.fdb $DestDir/help
 #cp -r $BuiltFBDir/doc $DestDir 
 
 cp $BuiltFBDir/firebird.msg $DestDir/firebird.msg 
-cp $BuiltFBDir/security.fdb $DestDir/security.fdb.sample
+cp $BuiltFBDir/security2.fdb $DestDir/security2.fdb.sample
 
 
 #cp $BuiltFBDir/include/gds.f $DestDir/include 
@@ -282,7 +282,7 @@ chmod ug=rw,o= help/*.fdb
 # install the samples if they don't exist
 [ -f aliases.conf ] || install -o firebird -g firebird -m 440 aliases.conf.sample aliases.conf
 [ -f firebird.conf ] || install -o firebird -g firebird -m 440 firebird.conf.sample firebird.conf
-[ -f security.fdb ] || install -o firebird -g firebird -m 660 security.fdb.sample security.fdb
+[ -f security2.fdb ] || install -o firebird -g firebird -m 660 security2.fdb.sample security2.fdb
 
 # remove any existing gds service
 cp /etc/services /etc/services.old

builds/install/arch-specific/netbsd/install.sh.in

@@ -31,7 +31,7 @@
 #   Contributor(s):
 #  	James K. Lowden <jklowden@schemamania.org>
 # 
-#   $Id: install.sh.in,v 1.1 2004-05-20 23:04:23 skidder Exp $
+#   $Id: install.sh.in,v 1.2 2005-03-05 01:43:50 robocop Exp $
 # 
 
 #  Install script for FirebirdSQL database engine
@@ -171,7 +171,7 @@ copyIfExists $BuiltFBDir/help/help.gbak $DestDir/help  || exit
 cp $BuiltFBDir/help/help.fdb $DestDir/help  || exit
 
 cp $BuiltFBDir/firebird.msg $DestDir/firebird.msg  || exit
-cp $BuiltFBDir/security.fdb $DestDir/security.fdb.sample || exit
+cp $BuiltFBDir/security2.fdb $DestDir/security2.fdb.sample || exit
 
 cp $BuiltFBDir/include/*.h $DestDir/include || exit 
 
@@ -288,7 +288,7 @@ chmod ug=rw,o= help/*.fdb || exit
 # install the samples if they don't exist
 [ -f aliases.conf ] || install -o firebird -g firebird -m 440 aliases.conf.sample aliases.conf
 [ -f firebird.conf ] || install -o firebird -g firebird -m 440 firebird.conf.sample firebird.conf
-[ -f security.fdb ] || install -o firebird -g firebird -m 660 security.fdb.sample security.fdb
+[ -f security2.fdb ] || install -o firebird -g firebird -m 660 security2.fdb.sample security2.fdb
 
 #
 # add the gds service, if need be, and restart inetd

builds/install/arch-specific/sinixz/prototype.in

@@ -1,4 +1,4 @@
-# $Id: prototype.in,v 1.5 2004-04-27 12:37:10 brodsom Exp $
+# $Id: prototype.in,v 1.6 2005-03-05 01:43:55 robocop Exp $
 #-------------------------------------------------------------------------------
 
 !SRCDIR=@NEW_FIREBIRD_DIR@
@@ -15,7 +15,7 @@ d none  /usr/lib     ? ? ?
 
 d none @prefix@ 0755 root root
 
-v CONFIG.prsv @prefix@/security.fdb=$SRCDIR/security.fdb  0666 root root
+v CONFIG.prsv @prefix@/security2.fdb=$SRCDIR/security2.fdb  0666 root root
 f none @prefix@/firebird.msg=$SRCDIR/firebird.msg  0644 root root
 f none @prefix@/de_DE.msg=$SRCDIR/de_DE.msg  0644 root root
 f none @prefix@/fr_FR.msg=$SRCDIR/fr_FR.msg  0644 root root

builds/install/arch-specific/win32/installation_readme.txt

@@ -59,7 +59,7 @@ Here are the steps in detail:
   1. Install to a new directory.
   2. Make a file copy of the old security database.
      (Make sure your old Firebird is not running.)
-  3. Start firebird using it's new, native security.fdb.
+  3. Start firebird using it's new, native security2.fdb.
   4. Connect to your old security database as SYSDBA and
      run the script.
   5. Stop firebird.

builds/posix/Makefile.in.firebird

@@ -27,7 +27,7 @@
 #  Contributor(s):
 # 
 #
-#  $Id: Makefile.in.firebird,v 1.59 2005-02-24 12:23:14 alexpeshkoff Exp $
+#  $Id: Makefile.in.firebird,v 1.60 2005-03-05 01:44:02 robocop Exp $
 #
 
 ROOT=..
@@ -148,7 +148,7 @@ firebird_super firebird_server: firebird_basic super_targets
 
 
 # In building embedded/server version some targets are common, mainly the 
-# boot kit, security.fdb database and messages files.  Boot builds a number of
+# boot kit, security2.fdb database and messages files.  Boot builds a number of
 # static programs gpre_static gbak_static isql_static though an involved 
 # process.  These are used to compile the rest of the source, as it saves
 # some complications particularly for super in needing to start the server
@@ -246,10 +246,10 @@ lock_mgr :
 #  (It's probably possible to directly build the dynamic library - but thats
 #  for another day). We still don't have the security database stuff.
 #
-# Phase2 is complete with the building of an security.fdb user store database
+# Phase2 is complete with the building of an security2.fdb user store database
 # in order to do that isql and gdef tools need to be built without security
 # to do that a special alt_boot.o is inserted into the shared library.
-# Again once security.fdb is built then were not too worried about the
+# Again once security2.fdb is built then were not too worried about the
 # components (in fact some of them have to be rebuilt again to incorperate
 # the security module)
 #
@@ -294,8 +294,8 @@ security2.fdb: gdef isql 		# build the security database
 #  for another day). We still don't have the security database stuff.
 #
 # Notes:
-# mainly we need gdef and isql to be able to build security.fdb.  I wonder
+# mainly we need gdef and isql to be able to build security2.fdb.  I wonder
-# if we could reduce the tricky dependancy by restoring the security.fdb
+# if we could reduce the tricky dependancy by restoring the security2.fdb
 # database earlier, then perhaps we could build the jrdlib in one step and
 # include the security bits and pieces.
 

builds/posix/Makefile.in.libfbclient

@@ -27,7 +27,7 @@
 #  Contributor(s):
 # 
 #
-#  $Id: Makefile.in.libfbclient,v 1.27 2005-01-13 07:28:32 aafemt Exp $
+#  $Id: Makefile.in.libfbclient,v 1.28 2005-03-05 01:44:03 robocop Exp $
 #
 ROOT=..
 ObjModuleType=superclient
@@ -42,7 +42,7 @@ include     $(ROOT)/gen/make.shared.variables
 
 
 # These are deliberatly unexported otherwise gbak and others will try and check
-# the userid against the security.fdb database, which doesn't exist at this stage 
+# the userid against the security2.fdb database, which doesn't exist at this stage
 # in the build. MOD 11-July-2002
 
 unexport ISC_USER

builds/posix/Makefile.in.libfbembed

@@ -27,7 +27,7 @@
 #  Contributor(s):
 # 
 #
-#  $Id: Makefile.in.libfbembed,v 1.13 2004-04-30 23:02:06 brodsom Exp $
+#  $Id: Makefile.in.libfbembed,v 1.14 2005-03-05 01:44:03 robocop Exp $
 #
 ROOT=..
 ObjModuleType=std
@@ -42,7 +42,7 @@ include     $(ROOT)/gen/make.shared.variables
 
 
 # These are deliberatly unexported otherwise gbak and others will try and check
-# the userid against the security.fdb database, which doesn't exist at this stage 
+# the userid against the security2.fdb database, which doesn't exist at this stage
 # in the build. MOD 11-July-2002
 
 unexport ISC_USER

builds/posix/Makefile.in.refDatabases

@@ -27,7 +27,7 @@
 #  Contributor(s):
 # 
 #
-#  $Id: Makefile.in.refDatabases,v 1.25 2005-02-24 12:23:14 alexpeshkoff Exp $
+#  $Id: Makefile.in.refDatabases,v 1.26 2005-03-05 01:44:03 robocop Exp $
 #
 ROOT=..
 ObjModuleType=std
@@ -40,7 +40,7 @@ include     $(ROOT)/gen/make.shared.variables
 @SET_MAKE@
 
 # If we export the username/password we get an error because we can't connect
-# to security.fdb!  So we won't export them while we make the databases...
+# to security2.fdb!  So we won't export them while we make the databases...
 #
 unexport ISC_USER
 unexport ISC_PASSWORD

doc/README.NTSecurity

@@ -28,7 +28,7 @@ The steps to fix things manually are simple:
     with default rights
  
 2)  grant this user write access to all databases, including 
-    security.fdb (isc4.gdb in pre-1.5 versions), and the 
+    security2.fdb (isc4.gdb in pre-1.5 versions), and the
     firebird.log file
 
 3)  grant the user 'firebird' rights to "Login as service" 

doc/README.instsvc

@@ -9,11 +9,11 @@ NOTE :: To solve any potential issues with long paths containing spaces
   RootDirectory as a command-line argument.  Both binaries must be installed 
   in (or copied to) the /bin directory beneath your Firebird root directory.  
 
-  (Root directory == directory root where firebird.conf and security.fdb are
+  (Root directory == directory root where firebird.conf and security2.fdb are
                      installed.)  
 
-  For example, if they are located in C:\FB15\bin, the root directory will 
+  For example, if they are located in C:\FB20\bin, the root directory will
-  be deduced as C:\FB15.
+  be deduced as C:\FB20.
 
 ============
 INSTREG.EXE

doc/README.sha1

@@ -6,12 +6,12 @@ WARNING! Firebird security level is still not satisfactory in one serious aspect
 
 	Very important security problem of firebird, which is still unresolved - transmission of badly encrypted passwords (read - clear) across network. Unfortunately, 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 the server with old client. This fact (and plans to upgrade some aspects of API in 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-tunneling software (like ZeBeDee) to move data to and from firebird server (this is true for both 1.5 and 2.0) and this is recommended way to access your remote firebird server across internet.
 	Special attention was paid to the following aspects of security:
-	- none brute-force resistant passwords encryption in security.fdb;
+	- none brute-force resistant passwords encryption in security2.fdb;
-	- ability for any remote user (with valid account) to open security.fdb and read hashes from it (specially interesting in combination with previous point);
+	- ability for any remote user (with valid account) to open security2.fdb and read hashes from it (specially interesting in combination with previous point);
 	- inability for user to change his/her own password;
 	- no protection from remote brute-forcing of passwords on the server directly. 
 	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 before comparison with hash stored in security database. But this sequence becomes completely broken when one SYSDBA changes password - client performs hash calculation twice and stores resulting hash directly in security database. Therefore hash management is completely client-dependent (or even better to say client-defined). 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 today gsec and isc_user_add(modify, delete) API both use services to access security database (with exception of embedded access to POSIX CS, see below). Now it became quite easy to make any changes to way of passwords hashing - it's always performed by server. Should notice, that new gsec successfully works with old firebird 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 calculated as SHA1 (salt || username || password)). This method leads to the facts that (first) hash valid for user A is invalid for user B and (second) when user changes his password even to absolutely the same as later, new data is stored in PASSWORD field of security.fdb. This facts don't increase resistance to any attempt to brute-force password, but make "visual" analysis of stolen password database much harder.
+	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 calculated as SHA1 (salt || username || password)). This method leads to the facts that (first) hash valid for user A is invalid for user B and (second) when user changes his password even to absolutely the same as later, new data is stored in PASSWORD field of security2.fdb. This facts don't increase resistance to any attempt to brute-force password, but make "visual" analysis of stolen password database much harder.
 	One of the problems, solved during security review, was old gsec. Certainly, no one can change data in security database without correct password knowledge, 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 server becomes impossible. Therefore special measures were taken to make remote connection to security database impossible at all. Don't be surprised if some old program, 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 used 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 there are also some small differences. In firebird 1.5 table USERS had to be readable by PUBLIC - it was engines requirement, otherwise process of password validation failed. In Ivan's patch solution with view, having condition USER = '' in where 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. After fixing that bug, it was certainly possible to add condition USER = 'authenticator', which in short-term was OK, because normal username is always converted to upper case. But better solution was found, and now user authentication process does not depend from such tricks. As the result - non-SYSDBA user can see only 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 brute-force password. Taking into account, that maximum password length is 8 bytes, this is a bit possible for firebird. Version 2.0 has protection from it - after too many attempts to enter wrong password authentication process is locked for a while, minimizing the chance of finding correct password during reasonable time.

doc/README.user.embedded

@@ -1,5 +1,5 @@
 -----------------------------------------------------------
-Firebird 1.5 Embedded Server notes
+Firebird 2.0 Embedded Server notes
 -----------------------------------------------------------
 
 1. GENERIC INFORMATION
@@ -32,7 +32,7 @@ Firebird 1.5 Embedded Server notes
 
   2.3. Authentication and security
 
-    The security database (namely security.fdb) is not used
+    The security database (namely security2.fdb) is not used
     in the embedded server and hence is not required. Any
     user is able to attach to any database. Since both
     the server and the client run in the same address space,

doc/WhatsNew

@@ -14,6 +14,7 @@
 
     * Security improvement
         Another layout of security.fdb
+        Also, security.fdb has been renamed security2.fdb
       Contributor(s):
         Alex Peshkov <peshkoff at mail.ru>
 

src/dbs/security.gdl

@@ -16,7 +16,7 @@
  * All Rights Reserved.
  * Contributor(s): ______________________________________.
  */
-modify database "security.fdb" security_class database_access;
+modify database "security2.fdb" security_class database_access;
 
 /*