Final Word on the Password Problem

[Nancy Palmquist]

Here is my reply to my esteemed colleagues points and arguments:

1) Bob Stockler & JP - I prefer a site password because of the nature of
the site password function.  As this customer found out, a site password
was assigned - unknown and unnoticed - it connected itself to many
process tables before it was discovered.  Then it was a real headache to
remove.  

Using the Option and changing the password on each and every table if
you find a way to load them, or if they are in ASCII using VI to remove
them or paying fpTech to remove them if they are encrypted.  All this
could have been avoided if the password had been assigned by the
developer/user.  

2) Mark - Write it down.  This password is assigned and on the machine
that is the development system, it is never seen again if you are
lucky.  Never is a long time but my memory is not that good.  I keep a
password safe with all the appropriate passwords.  I suggest to users to
keep a written file of these kinds of passwords, in a sealed envelope in
the company safe.  To protect the company assets just like you keep the
money.  If some time passes and the employee that setup the system
leaves, the owner will know that the next person will be able to get any
needed passwords, licenses, system information, registrations and the
like.  

I agree that security passwords that require you to access sensitive
information should be committed to memory, but the site password is
hardly that.  I would also recommend that the creation passwords be
noted, if used.  It may be some years between when you choose to assign
them and when you next need to access them.  It is not incorrect to
document them so they will be available when you need them.

3)ASCII - is a great way to store all process tables.  I do it myself. 
It will allow you to read the table from outside filePro, it reduces the
load time for editing and running if you are using the dclerk/dreport
versions of filePro.

However, the Quickstart stuff is still very useful as I recently
discovered for one of my big customers.  It runs faster than the non
quickstart version.  I couldn't believe it but it ran noticeably faster
- not just the load time but from record to record processing time. 
Since all installations of 5.0 include quickstart, you can use both as
needed.

4) Bob Stockler - changing permissions on /etc/default/fppath seems
foolish to me.  The first time someone runs setperms it will be changed
back to the standard.  Then you suggest a change to the fp.list file and
when the next update happens that gets set back.  No, I try to stick
with the default way filepro installs and permission itself.  If you
think that you have blocked someone from changing the fppath, and the
permissions revert in an upgrade, you are not watching to see if it is
assigned, and whamo you have the site password changed again.  Just
assign one and be done with it.

5) Bob & Mark - I know that Unix will accept a long password but will
only respect the first part of it.  I know I assigned a very long
password as the root password on a Unix system, such as
"McDonaldSalesCompany".  I have easily been able to login with only
"McDonaldSales" with no problem.  Not sure how many other letters I can
drop to gain access.
BTW I did this to make it difficult for the customer to log in as root. 
IT did not stop them.  And Mark before you panic, and post that the
password is too easy to figure out, this system is totally internal and
has no access to the outside world, you can't get too much more secure
than that with regard to hackers.  Employees own the place and in the 20
years we have worked with them, no one has ever even tried to bother
with the operating system.  Most stable computer system I ever
installed.  They call to to ask how to reboot since they do it only
every few years.  Love that Unix stuff.

Vicki - These are my arguments.  You, of course, will make your own
decision but I highly recommend a site password be assigned on any Unix
system.  You will never again be stuck with processing tables you do not
know how to open.


-- 
Nancy Palmquist 
Virtual Software Systems
PHONE: (412) 835-9417			Web site:  http://www.vss3.com