| Subject | The MS Access security model |
|---|---|
| Author | GOVINDKRISHNA |
| Post date | 2004-04-06T15:00:39Z |
Hi,
First let me define the environment. When we are talking about enterprise class applications, you could say secure the access to the data files and that is sufficient. But in applications which are being shipped to smaller organisations where there is no qualified system adminstrator the situation changes. Typically these were MS Access apps, now firebird is a very attractive alternative. Here the problem, you cannot assume administrator created security restrictions. Your application has to provide its own.
The scenario to worry about is if the customer has entered sensitive information in the application he wants to be sure that his business rival cannot just tip his employee to take across the backup. Even if the business rival has the same application and tries to restore the backup the data should still be secure.
In this environment the MS Access security model is quite interesting. I would like to share what I know of it and how I used it. I will use firebird terminology so that it is easier to understand. ( I will say isc4.gdb instead of system.mdw or sysdba instead of adminsitrator)
Access ships with a default isc4.gdb with a precreated sysdba account which has a Personal Id of 1. A hash of the sysdba and the personal id of the sysdba is taken and this what is associated as owner / creator when database objects are created.
If I connect using the standard isc4.gdb and username sysdba I have all rights to database objects created with the default isc4.gdb because the owner hash is the same as the login hash.
However an option is available to create a custom isc4.gdb with username sysdba but different personal id for e.g. 56353 (Any int I enter it when creating the custom isc4.gdb). Now a different hash is created for sysdba. If i create a database "secure.gdb" logging in as sysdba the owner of the database objects is now a hash associated with sysdba in the custom isc4.gdb.
If I login as sysdba using the standard isc4.gdb since the owner hash does not match the login hash even sysdba has no right to access the data.
If I have to connect I have to use the custom isc4.gdb and know the sysdba password in the custom isc4.gdb
Given this how do I secure the data. When installing the software I ask for a master password and a master number . I create a custom isc4.gdb which uses this number as the personal id and the master password is used as the sysdba password. I ask the user to save this away carefully. I securely encrypt the master password and save it in the registry. I create my database using this custom isc4.gdb. When ever i connect to the database I use the custom isc4.gdb and decrypt the sysdba password from the registry.
The day to day users of the software do not know the master password or the master number. Even if they take the backup from my software and restore it at a different location the information is not visible unless they know the master password and master number. And use these numbers when installing my application.
BTW the password level security that access provides is a very simple thing and is easily breakable. The custom isc4.gdb is not easily breakable at all.
HTH
gk
First let me define the environment. When we are talking about enterprise class applications, you could say secure the access to the data files and that is sufficient. But in applications which are being shipped to smaller organisations where there is no qualified system adminstrator the situation changes. Typically these were MS Access apps, now firebird is a very attractive alternative. Here the problem, you cannot assume administrator created security restrictions. Your application has to provide its own.
The scenario to worry about is if the customer has entered sensitive information in the application he wants to be sure that his business rival cannot just tip his employee to take across the backup. Even if the business rival has the same application and tries to restore the backup the data should still be secure.
In this environment the MS Access security model is quite interesting. I would like to share what I know of it and how I used it. I will use firebird terminology so that it is easier to understand. ( I will say isc4.gdb instead of system.mdw or sysdba instead of adminsitrator)
Access ships with a default isc4.gdb with a precreated sysdba account which has a Personal Id of 1. A hash of the sysdba and the personal id of the sysdba is taken and this what is associated as owner / creator when database objects are created.
If I connect using the standard isc4.gdb and username sysdba I have all rights to database objects created with the default isc4.gdb because the owner hash is the same as the login hash.
However an option is available to create a custom isc4.gdb with username sysdba but different personal id for e.g. 56353 (Any int I enter it when creating the custom isc4.gdb). Now a different hash is created for sysdba. If i create a database "secure.gdb" logging in as sysdba the owner of the database objects is now a hash associated with sysdba in the custom isc4.gdb.
If I login as sysdba using the standard isc4.gdb since the owner hash does not match the login hash even sysdba has no right to access the data.
If I have to connect I have to use the custom isc4.gdb and know the sysdba password in the custom isc4.gdb
Given this how do I secure the data. When installing the software I ask for a master password and a master number . I create a custom isc4.gdb which uses this number as the personal id and the master password is used as the sysdba password. I ask the user to save this away carefully. I securely encrypt the master password and save it in the registry. I create my database using this custom isc4.gdb. When ever i connect to the database I use the custom isc4.gdb and decrypt the sysdba password from the registry.
The day to day users of the software do not know the master password or the master number. Even if they take the backup from my software and restore it at a different location the information is not visible unless they know the master password and master number. And use these numbers when installing my application.
BTW the password level security that access provides is a very simple thing and is easily breakable. The custom isc4.gdb is not easily breakable at all.
HTH
gk
>>> This mail is created in Hamsa (www.jlmatrix.com) <<<