a user security hole in mindterm's ssh 2 applet

[Stephen Adler]

Mats,

thank you very much for your reply but this is a big concern
for us. Here's the problem. We cannot trust the users to be
security conscious. We must assume that if there is something
a user can do to leave his password open, they will, even though
they don't intend to. Secondly, we are using mindterm as the
official way of giving access to our systems from insecure
places around the world. We have professors who travel to
countries around the world who will being gaining access to
our computer systems.

We are a Department of Energy facility and we are under a
microscope these days regarding computer security. Remember
the Win Ho Lee case of Los Alamos National Labs? Well Brookhaven
National Labs is a "sister" research facility managed by the
same federal department. (i.e. Department of Energy) We are
undergoing a large scale security restructuring of our computer
systems and we will be reviewed and audited by DOE to ensure
that our security model is acceptible. If I show up to a review
and explain to them that we are using a software product which
if you do xyz, then a windows PC in some foreign country will
have a hostname/username/password such that anyone can gain
access to the system, we will flunk the review.

Mats, is it possible to get appgate to modify your mindterm
product so that we can disable the password saving feature
and still use the signed version of the applet? (As I understand,
scp does not work with the unsigned version, otherwise
we would use the unsigned version.) Who at appgate could I call
to explain our situation? In your estimate, how big a change
to mindterm would this be?

Thanks for the reply Mats

Steve 

On Thu, 2002-09-19 at 05:52, Andersson, Mats wrote:
> 
> On 18 Sep 2002, Adler, Stephen wrote:
> > discovered a rather ugly user enabled security hole in the mindterm
> >
> > the "save password" option, then not enter in a password to password
> 
> This is actually a "feature", it means that if you save your passwords
> et.c. without encrypting it (i.e. no passphrase given), it's going to save
> it unencrypted (so it can be retrieved without user intervention).
> 
> > to find a way to close this hole, either by setting up some way of
> > disabling the saving of passwords, or forcing the user to enter in a
> > password to encrypt the local password file.
> 
> Saving passwords is disabled by default. Entering an empty passphrase
> should perhaps warn people what it implicates to do that. You might also
> have a point in the need for a special setting which entirely disables the
> option to use it too (or something forcing a passphrase and hence
> encryption).
> 
> I wouldn't consider this a very grave security-issue though, even a normal
> user probably understands that he shouldn't enable saving passwords on a
> computer that anybody can access freely (even when giving a passphrase to
> encrypt it).
> 
> Cheers,
> 
> /Mats
>