Conference bulova::decw_jan-89_to_nov-90

	Corporate Policy states that all employees should have their
	own account for which they are solely responsible. Why not just
	give them all seperate accounts? Secondary passwords on shared
	accounts doesn't make any security sense.

								mike

    Also having primary/secondary passwords makes more sense when
    two people have to type in one of the passwords and neither knows
    both.  If one person types in both passwords, then that is no
    more secure than having one long primary password that is the
    concatentation of both primary/secondary passwords.
    
    				-John

    The statement that one long password is as secure as two short ones
    is not strictly true. Because VMS maps a password to a long word
    the password is not unique. (For example aaaaaaaabbbbbbbb is equivalent
    to bbbbbbbbaaaaaaaa as a password. that is if one of these is set
    as a password the other password will be accepted by VMS). Thus
    if security is measured as the number of random attempts needed
    to guess the password successfully two short passwords will require
    much more guessing than one long one.
    
           Mike 

Re .1-.3.  Woops, my mistake.  The 'secondary password' scheme I referred to
in .0 is not the VMS documented secondary password scheme.

We have a captive group account that runs an internally-generated program, that
prompts for a user/password pair, which is verified against a data file.  It's
this second 'username' prompting that is hanging the login/creation of the
DECwindow processes.

Now, any thoughts?

tl

The same criticism applies.

As for .3: If the password is good, then it takes 2 billion tries to find
it by exhaustive search.  (Or is the has a quadword?  2 billion is for
a longword.)  So your statement is correct but it doesn't make any
practical difference.

	paul

    I agree with Paul's comment that my comment on passwords is largely
    theoretical. However there are ways of getting at passwords other
    than exhaustive search as I know from personal experience of fighting
    hackers in an Academic environment. In that situation I found secondary
    passwords a useful further protection to standard constraints on
    the passwords people use. (Also I guess Paul is right; our passwords
    are quadwords which suggests that properly constructed single passwords
    are very secure.)
    
    Mike.

Dispensing of the rathole about the use/non-use of secondary passwords and 
getting back to the original topic:

>We have a captive group account that runs an internally-generated program, that
>prompts for a user/password pair, which is verified against a data file.  It's
>this second 'username' prompting that is hanging the login/creation of the
>DECwindow processes.

Creating a DECterm via the session manager will run SYLOGIN.COM and LOGIN.COM
twice -- the first time as a mailbox (MB), the next as a terminal window (TW).  
It sounds as if your program is getting hung up with the MB device.  Try 
modifying your login to test what device is being used:

	$ if f$getdvi("sys$output","trm") .and. -
	  f$extract(1,3,f$getdvi("sys$output","devnam")) .eqs. "TWA" then -
	$ run internally_generated_program

Hope this helps...

-Andy

Another suggestion would be to test for the DECW$DISPLAY logical and if
defined, have the program present a dialogue box asking for the password.
The question then becomes would you want to be nice and allow autologin to
occur for subsequent decterm creations? Or, would you want the user to 
respecify the password?

BTW. The code in .-1 will stop working with the release of DECwindow V3.
The device name for the pesudo-terminal will be changing. The new device is
named FTAx:. If you adopt such a scheme you might want to anticipate the 
change so all you users don't wonder what happened one day to cause everything
to break.

Also, I just noticed the test in .-1 does not run the program for normal VTxxx
terminals. It appears to assume the choice of either mailbox or decterm. What 
happens if someone hacks you by hooking up the console terminal?

James

Well, I provided the code in .7 more as workaround, not solution.  Of course,
if the program was, indeed, getting hung up with the mailbox, he could try
doing:

	$ if f$getdvi("sys$output","trm") .and. -
	  f$extract(1,2,f$getdvi("sys$output","devnam")) .eqs. "MB" then -
	$ exit

but then this would filter -all- mailboxes from the procedure.  This may or
may not be desired.

-Andy

    There's no reason to look at physical device names at all!  The one
    condition you care about is whether this login is connected with a
    'command terminal'.
    
    All you really need is:
    
    $ if f$getdvi("SYS$COMMAND","trm") then do_secondary_password
    
    	[possibly combined with a test for (f$mode() .eqs. "INTERACTIVE")]