Password Problem Revisited

[Kenneth Brody]

Vicky Prigg wrote:
> 
> Despite some good suggestions, we have not solved our password problem.
> It is not a site password as some have suggested, rather it is a
> 'processing password' that has somehow been acquired by some (not all)
> of our processing tables.

While "site password" and "processing password" are not identical, they
are related, and often the term "site password" is used to mean both.
When a processing table is first created, or when one that does not have
any processing password already assigned, it will be saved with the
current site password as its processing password.

> It was not a one time thing that happened to
> all the processing tables present at the time.  It happened to a few,
> while not affecting others.  And, it is not a case where someone gave a
> password to a processing table and forgot it.   We cannot use backup
> tapes because they have long since been recycled.
[...]
> Also, if anyone has any ideas as to how this happened in the
> first place, please let me know!

Check the dates of those tables that are now asking for the password.
You will likely see that they all were modified during a certain date
range, and that none of the others were modified during that time.
What happened is that, at the beginning of that time period, someone
had placed a site password on that system.  Then, at the end of that
time period, someone removed the site password.  (Check the date of
the fppath file, and you will see that it has been recently modified.
That date is probably the same date that you started being asked for
the password.)

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody at spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+