PRODUCT:  R:BASE                    VERSION :  3.1 or Higher
     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.
     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
     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.        
     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.
     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?