milest wrote:
How easy is it for someone to use a non ACCESS (but easily available)
programme to alter numerical values in an ACCESS database table and
save the result in a way which continues to allow the db to be opened
by ACCESS - I want to prevent this (have already prevented shift-key
access). Not sure what programmes could do this but thought this is
what the ACCESS encryption facility is meant to prevent.

I encrypted an ACCESS database and opened it with Wordpad/Excel but
found that the numerical values did not seem to be encrypted and
EXCEL could still read the tables!

Overview of Access security

There are different strategies for controlling the level of access to your
Microsoft Access database and its objects. These strategies are briefly
described below and are roughly arranged from least to most secure.

Encryption/decryption

The simplest method of protection is to encrypt the database. Encrypting a
database compacts the database file and makes it indecipherable by a utility
program or word processor. Encrypting an unsecured database has no effect
because anybody can open the database and gain full access to all objects in
the database. Encryption is particularly useful when you transmit a database
electronically, or when your store it on floppy disk, tape, or compact disc.

Before you can encrypt or decrypt a Microsoft Access database, you must be
either the owner of the database or, if the database is secured, a member of
the Admins group of the workgroup information file that contains the
accounts used to secure the database. You must also be able to open the
database in exclusive mode, which means you must have Open/Run and Open
Exclusive permissions.

Decrypting a database reverses the encryption.

Show or hide objects in the Database window

Another method of protecting the objects in your database from casual users
is to hide the objects in the Database window. This method of protection is
the least secure because it is relatively simple to show any hidden objects.

Using startup options

You use the startup options to specify settings such as a startup form,
which opens automatically when your database opens, and your database
application title and icon. You can also hide the Database window, and set
your own switchboard form. In a new database, the startup properties do not
exist until a user makes a change to the default settings in the Startup
dialog box.

With a password

Another simple method of providing security is to set a password for opening
the Microsoft Access database. Once a password is set, a dialog box that
requests the password will be displayed whenever the database is opened.
Only users who type the correct password will be allowed to open the
database. This method is secure (Microsoft Access encrypts the password so
that it can't be accessed by reading the database file directly), but it
only applies to opening a database. Once a database is open, all its objects
are available to the user (unless other types of security have already been
defined, as described later in this topic). For a database that is shared
among a small group of users or on a single computer, setting a password is
often all that is required.

Do not use a database password if you will be replicating a database.
Replicated databases can't be synchronized if database passwords are
defined.

With user-level security

The most flexible and extensive method of securing a database is called
user-level security. With user-level security, you can establish different
levels of access to sensitive data and objects in your database. To use a
database secured with user-level security, users type a password when they
start Microsoft Access. Access reads a workgroup information file, where
each user is identified by a unique identification code. The level of access
and the objects that a user has access to are established based on this
identification code and password.

Although setting up user-level security on most databases can be a daunting
task, the User-Level Security Wizard makes it easy to quickly secure your
Access database in a one-step process. Furthermore, by implementing common
security schemes, the User-Level Security Wizard minimizes and may even
eliminate the need to use the Security command from the Tools menu.
After running the User-Level Security Wizard, you can create your own groups
of users and assign or remove permissions for various users or group of
users for a database and its existing tables, queries, forms, reports, and
macros. You can also set the default permissions that Microsoft Access
assigns for any new tables, queries, forms, reports, and macros that are
created in a database. Permissions are granted to groups and users to
regulate how they are allowed to work with each table, query, form, report,
and macro in a database.

Preventing users from replicating a database, setting passwords, or setting
startup options
In a multiuser environment, there are many situations where you might need
to protect your database. You might want to prevent users from replicating a
database. Replicating a database allows a user to make a copy of a shared
database and also adds fields and makes other changes to the current
database. You might want to prevent users from setting a database password,
because if they do, no other user will be able open the database without
providing that password. You might also want to keep users from changing
startup properties that specify features such as custom menus, custom
toolbars, or the startup form.

If a shared database doesn't have user-level security defined, you can't
prevent a user from making any of these changes. When user-level security is
defined, a user or group must have Administer permission for the database to
replicate a database, set a database password, or change its startup
properties. Only members of the Admins group of the current workgroup have
Administer permission.
If a user or group currently has Administer permission for a database,
removing that permission will prevent the user or group from making any of
these changes. If you need to allow a user or group to perform any of these
tasks, you can assign the Administer permission to that user or group. You
can't control access to these three tasks independently.

Securing Microsoft Visual Basic for Applications (VBA) Code
There are two different ways you can protect Microsoft Visual Basic for
Applications (VBA) code in standard modules and class modules (such as code
behind forms and reports).

You can secure your code with a password, which you enter once per session.
The password prevents unauthorized users from editing, cutting, pasting,
copying, exporting, and deleting VBA code.

When your VBA code is error-free and working correctly, you can remove it
from your database by saving it as an MDE file. This protects the
intellectual property of your code, and prevents modifications to the design
of forms, reports, and modules in your database.

Securing data access pages
Data access pages are HTML pages that contain references to the data in a
Microsoft Access file. However, the data access pages aren't actually stored
in the Access file; they are stored as HTML files either in the local file
system, in a folder on a network share, or on an HTTP server. For this
reason, Microsoft Access has no control over the security of data access
page files. To protect the data access page, you must secure its link and
HTML file by using the file system security of the computer where you have
stored these files. To protect the data accessed by the page, you must
either secure the database that the page is connected to or configure
Microsoft Internet Explorer security settings to prevent unauthorized
access.


Other than a design change, if I want to stop users being able to
alter
table values in this way, are there better ways than encrypting the
mde file; what other (unwanted!) deployment implications might
encryption create? The db was to be deployed as an unencrypted
ACCESS 2002/2003 file format mde file.

--
Joseph Meehan

26 + 6 = 1 It's Irish Math