Final Word on the Password Problem

[Nancy Palmquist]

Kenneth Brody wrote:
> 
> "Jay R. Ashworth" wrote:
> [...]
> > > > > > > However, it you change the password such
> > > > > > > that the processing table's password no longer matches the
> > > > > > > site password, then filePro will start asking for the password
> > > > > > > before you can see/edit the processing.
> [...]
> > > _Which_ "*which* password" are you referring? There's the password in
> > > the processing table, the site password in the original machine, and
> > > the site password on the new machine. I also mentioned changing the
> > > site password, as well as passwords matching or not.
> >
> > I'm referring to "the password which filePro will start asking for".
> 
> Since we are referring to "before you can see/edit the processing",
> I am obviously referring to the processing's password.  (What other
> password would filePro want at that point?)
> 
> [...]
> > > If the password stored in the table does not match the current site
> > > password, then you need to know the password in the processing table
> > > in order to view it. (No password is needed to run it.)
> >
> > "...using dcabe."
> 
> ... or dclerk or dreport.
> 
> >  Obviously if it's in ASCII, you don't need to know
> > that password to edit it in vi.
> 
> Correct.
> 
> > So, Nancy's advice, which *sounds like* "run right out and set site
> > passwords on all your machines right now" to *me* is indeed bad,
> > because it won't protect most of those files until they're touched by
> > dcabe, which could take forever.
> 
> In this case, we're talking about "protecting" them from getting a password
> that you don't know, so Nancy's advice still holds here.
> 
> > It's really only useful advice for developers on development machines
> > freshly installed, with no work done on them yet, as far as I can see.
> > Am I missing something?
> 
> Let's get back to the OP's problem.  They had a system which probably
> didn't have a site password.  At some point, someone set a site password,
> and new/modified processing tables started to get that password which was
> unknown to the OP.  Sometime later, someone, somehow, changed the site
> password to something else.  (Perhaps they moved to a different machine?)
> At that point, all of those processing tables that were created/modified
> in the interim had a password unknown to the OP, and were inaccessible.
> 
> Nancy's position, as I understand it, is that had the machine(s) all had
> a known site password, this unknown password should never had snuck into
> these processing tables.


Yes that is exactly my point.

I am suggesting that if you do not have a site password, assign one now
that you know.  If your tables have none, it will not bother you at
all.  As you edit or add tables it will attach to those tables.  You
will still never notice the password.

So what is the problem with my approach on any system, development or
end user?

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