DOCUMENT #676
=======================================================================
DATABASE PROTECTION -- MORE THAN JUST PASSWORDS
=======================================================================
PRODUCT: R:BASE VERSION : 3.1 or Higher
=======================================================================
AREA : DATABASE INTEGRITY CATEGORY: SECURITY
=======================================================================
From: Robert Saunders
Business Systems Consulting
59 E. Linden Ave., B7
Englewood, NJ 07631
(201) 568-3919
A database is valuable. It contains crucial company data, such as
financial information or critical customer contacts. Some companies
would go out of business if they lost their data, or if someone else
knew it. Some data, like medical records, is highly confidential. At
the least it represents hours of a developer's effort. So it makes
sense to take precautions to protect your work, especially when the
precautions can be so simple.
The major threats to a database are not renegade hackers. Ignorance
and simple user mistakes are much more frequent. I have seen more
hard disks accidentally formatted than I have seen viruses. More
money has been lost to "extra" paychecks than to teenagers who break
into a company's system for fun. So the first line of defense is
the people who will be working with the system. They should
be well chosen, well motivated and well trained. A little extra
money spent on training can save a lot of money spent trying to
recover a crashed database.
Backup
======
Then comes BACKUP!!! Working without adequate and regular backups is
like driving toward a cliff without brakes. With R:BASE commands,
backup can be done as part of an application; a menu choice that any
user can manage. The DOS BACKUP command can be used to backup up a
database to floppy disks. The DOS COPY command can be used to copy
the three database files to another location on your hard disk or to
floppy disk. There are many tape backup and third party backup
programs available. The capability to backup your database is there,
you need to be sure to use it.
Once you are in R:Base, there are two other kinds of
protection: program (logic) security, and password security.
Program Security
================
Program security requires a knowledge of the actual business and an
understanding of the system's uses. It includes "business rules." A
developer must understand the flow, and especially the limits, of
transactions. Using R:BASE data entry and delete rules can do more
than prevent inaccurate data from being entered; if an R:BASE form
lookup must succeed, it can save money.
For example, before a paycheck can be created, a lookup must find the
payee in the employee table. In another case, a payee must be in a
table of authorized vendors before their invoice can be paid.
Organizations depend on these safeguards every day. But program
security includes other logical tests. Even checking the free disk
space (ISTAT('diskspace')) before a BACKUP can avert disaster. All
these protections require a knowledge of the business and some
forethought.
Password Security
=================
R:BASE includes an extensive password protection system. The key to
the whole password process is the owner password. Until the owner
password is changed from the default PUBLIC, the rest of the password
protection system is not available. Once such a change is made, no
one can access the database without knowing the word. For many
simple business systems, this is sufficient security. It can be
invoked by the R:BASE menu system, or at the R> prompt. To make
OMHWTTC the password, just type RENAME OWNER PUBLIC TO OMHWTTC. The
owner password can be changed at any time by a similar command, and
should be changed periodically.
The R:BASE password system works to restrict access to your tables'
data. A developer cannot restrict specific menu choices of an
application to specific users based on password privileges.
GRANT/REVOKE
============
The GRANT/REVOKE passwords basically work table-by-table. GRANT
commands give the specified privileges on a table to the user of a
certain password. REVOKE takes them back. The same password can be
used to grant permissions for several tables, with varying
privileges, but a separate GRANT command must be issued for each
table. The GRANT command also has a WITH GRANT OPTION clause that
allows a password user to pass on privileges to others.
The privileges include SELECT (look but don't touch), UPDATE
(make changes within a row), INSERT (add a new row), and DELETE (a
row). UPDATE can be limited to only specific columns. Often it is
easier to GRANT ALL PRIVILEGES, then REVOKE certain ones. All
these options can lead to a maze of permissions and denials,
visible through the LIST ACCESS command.
Form Passwords
==============
A password for a form applies only to that form, and allows access
whether or not a user has GRANT/REVOKE permission to use the form's
tables. Without a form password, the SQL grant/revoke system applies.
Since the form password overrides other restrictions, it should be
used with caution.
Choosing Passwords
==================
Once you have decided on a password system for R:BASE, you have to
decide how it fits into your overall system. Some hardware can be
configured to require a password before booting. Most networks
require a login name and a password. So for larger systems, a user
may have several passwords to remember, and good managers change
passwords regularly. You may want to create R:BASE passwords that
match network passwords for convenience. Or you may want them
different for added security. So plan ahead to avoid confusion.
Unless users or managers choose good passwords the whole elaborate
system is worthless. Experts recommend long sets of random letters,
but they are hard to remember (without writing down--a no no). One
good method is to take a familiar phrase and use the initial letters
from it. The password used in the above example is from: Old Mother
Hubbard Went To The Cupboard and the next month you could change it
to TGTPDAB. These are hard words to crack, yet easy to remember.
Other Options to Protect Data
=============================
R:BASE also allows other ways to protect your investment. A database
can be connected as READ only when R:BASE is started. By setting
ESCAPE OFF within an application, you keep untrained users from
interrupting vital procedures. This is a common problem when a user
thinks a report is taking too long to print. SET LOCK tablelist
ON/OFF can temporarily lock/unlock one or more tables, preventing
users from accessing those tables.
External Controls
=================
Besides the controls built into R:BASE, there is a method of wider
scope to protect yourself. It is borrowed from the accounting
profession, where it is called separation of functions. As much as
possible, separate the programmers from the operators. That is, the
people who decide the structure and processing should not be the same
as those who enter the actual day-to-day data. Developers should work
with test data. A programmer should not be able to include an extra
payable voucher while doing routine upgrading. A payable clerk
should not be able to remove the controls on authorized vendors, and
include his cousin. This precaution will depend on the size and
intimacy of your shop, but is especially valuable when dealing with
outside developers.
Another threat is viruses. They are uncommon, but real. There is
good anti-virus software on the market. But it is important to
remember that viruses are only transmitted by executable files. The
*.RBF and *.AP? files cannot carry viruses. If you back them up, and
keep your original R:BASE installation disks safe, you can always
restore your system.
A determined, knowledgeable person has other ways to look at your
data, if that is all he wants. There are modern third-party DOS
shell programs that include file viewers. They can examine your data
in spite of passwords, albeit crudely. There are utilities that will
examine any sector on a disk, for that matter. Unerase programs can
find the temporary files R:BASE uses for sorting, and open them for
examination. There are even commercial programs that will find out
an R:BASE password--a necessity sometimes. These programs require
knowledgeable users and access to your system, but you should know
they exist. Only encryption programs can protect you from them, but
they make the system hard to use.
Conclusion
==========
So there are tradeoffs. A database of any value is worth protecting,
and many precautions are easy. Good people, a good backup, and an
owner password are enough for many systems -- simple, cheap and
effective. LAN-based multiuser systems need more elaborate
precautions. You have to ask yourself how much inconvenience is
necessary. How valuable is your system and your data?