Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!dww@seismo.CSS.GOV@stl.stc.co.uk
From: dww@seismo.CSS.GOV@stl.stc.co.uk
Newsgroups: mod.computers.vax
Subject: Re: PASSWORD VERIFICATION PROCEDURES
Message-ID: <8702120438.AA11744@mcvax.cwi.nl>
Date: Wed, 11-Feb-87 17:08:54 EST
Article-I.D.: mcvax.8702120438.AA11744
Posted: Wed Feb 11 17:08:54 1987
Date-Received: Fri, 13-Feb-87 21:43:12 EST
References: <8702100603.AA02948@ucbvax.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: David Wright <mcvax!stl.stc.co.uk!dww@seismo.CSS.GOV>
Organization: STL,Harlow,UK.
Lines: 11
Approved: info-vax@sri-kl.arpa

Both the macro program and the procedure using DECnet recently posted with the
above subject will no doubt allow a program to re-verify that the user is the
same person as he/she who originally logged on.   But the procedure outlined
could introduce a more serious security weakness than it solves.  I don't want
to outline the method in detail publicly, but getting users to re-enter their
passwords to a program is NOT a good idea.   UNLESS the user has a DIFFERENT 
password from their account-password, in which case it is only that special 
password which is at risk.

If you don't see why this is a weakness, mail me and I'll explain (if the 
return route works!!).