<snip>

>The reason I and the auditor asked about encrypting passwords is due to
>the fact that even if you are securing all logons with a Security/3000
>encrypted password and you restrict access to SM and PM users, if
>someone is able to gain access to a terminal logged on to an 'SM' user
>(i.e. like mine) and get the MPE password or if there is no MPE
>password (which isn't a good idea), you can still gain access to the
>HP3000 while bypassing Security/3000.  True,......

There is only so much that can be done using a tool and perhaps the rest
can be accomplished procedurally.  We also use Security/3000 but the
issue of 'unattended terminal' is addressed as follows:
  More than 10 years ago, before we got Security/3000, we developed a
simple program that would 'lockup' our terminal (disable break, ask for
password, go to sleep | awakened by ctl-y, ask for password, exit if
correct password) and 'got into the habit' of executing it *whenever* we
would walk away from our desk.  If we were to 'track' how often that
program gets executed each day it would rank within the top ten.

  Security/3000 also has a similar feature.  It is invoked with their
'lockup' UDC and uses the Security/3000 password to 'release' the
session.

  I'm sure that there will be cases when one forgets to 'lockup' or
thinks he will not be away long enough to warrant using the 'lockup'
feature, but I feel adherence to a simple 'manual' procedure would
substantially reduce the risk involved with 'unattended terminals'.


<snip>

Regards
Paul H. Christidis