A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Encrypt AccesS File?



 
 
Thread Tools Display Modes
  #1  
Old February 9th, 2005, 08:11 PM
milest
external usenet poster
 
Posts: n/a
Default Encrypt AccesS File?

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!

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.
  #2  
Old February 9th, 2005, 08:53 PM
Joseph Meehan
external usenet poster
 
Posts: n/a
Default

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


  #3  
Old February 9th, 2005, 08:58 PM
Dirk Goldgar
external usenet poster
 
Posts: n/a
Default

"milest" wrote in message
news
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!

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.


Unless you secure your database with user-level security, you will not
be able to keep people from opening the database, whether they do it
with Access or by way of a program (like Excel) that uses the Jet
database engine to manipulate the database directly without invoking
Access itself. And the help file says: "Encrypting an unsecured
database has no effect because anybody can open the database and gain
full access to all objects in the database."

You're going to need to implement user-level security if you want to
keep unauthorized people from reading -- and, potentially, modifying --
data values stored in the database. User-level security is tricky to
get right, though the User-Level Security Wizard in the most recent
versions of Access does a good job. You ought to read and study the
Security FAQ
(http://support.microsoft.com/default...b;en-us;207793) before
attempting to secure your database -- and make sure you have a copy of
the un-secured database tucked away, in case you inadvertently lock
yourself out.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Database design for a network AMY Z. New Users 16 February 12th, 2007 11:56 AM
Cannot open Microsoft Access 2000 database file Michele General Discussion 1 September 7th, 2004 06:11 PM
Adding staff photographs to my database KK New Users 2 September 3rd, 2004 07:41 AM
What is MDE Charlie General Discussion 4 August 24th, 2004 04:15 PM
Database Window Gone DaveB General Discussion 2 July 29th, 2004 12:24 AM


All times are GMT +1. The time now is 09:07 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.