l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised


From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Wed, 29 Mar 2006 14:27:39 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 29 Mar 2006 01:19:05 +0200,
Lluis <address@hidden> wrote:
> Hum... isn't all this overly complicated? I should have no doubts about 
> wether I'm talking to the real login manager or not... and in fact, if I 
> must be sincere (that I musn't, but I want to :)), this doesn't worry me on 
> my day-to-day work (like the inmense majority of home computer users, I'm 
> the administrator of it too... ough, did I say that this arises a problem 
> of self-confidence?), as I don't have any special feature to check wether 
> i'm using the trusted login... it's just that I trust on my debian to keep 
> up on the hard work :)

Complexity is in fact a major concern.  Good secure user interfaces
are simple.  So, let's look at the complexity of the proposed
strategy.  This would be a user documentation for a normal PC:

"Before you log on to the terminal, press the keys CTRL, ALT and
DELETE all at the same time to get to the log on dialog.  Do this also
if you think that the log on dialog is already displayed, because it
may be forged.  After you enter your account name, make sure that the
personal information displayed on the screen belongs to you, to verify
that you did not misspell your account name.  Then, confirm to log on."

I don't think this is overly complicated.  It could be simplified,
though, in the following ways:

1) Have a designated light indicator that is on if you talk to the
   system's log on dialog (for example the middle keyboard LED, or
   so).  Let's called this the "logged off" light.

2) Have a designated key for "terminal reset" at the terminal.

3) Use smart cards, memory sticks or some other physical item, which
   needs to be attached to the terminal and from which the user name
   is read.  Let's call this item the "account key".

With all these measures applied, the documentation could be as simple
as this:

"To log on, press the `Terminal Reset' button if the "logged off"
light is not on, and insert your account key into the designated slot
at the terminal."

That's really simple, isn't it?  In fact, the logged off light is
optional.  It could be as simple as this:

"To log on, press the `Terminal Reset' button and insert your account
key into the designated slot at the terminal.  Do never insert your
account key before first pressing the `Terminal Reset' button."

It could be even simpler.  Depending on how sophisticated you want it
to be, you could make log-off automatic if the account key is removed
from the hardware slot, by letting the terminal logon manager monitor
the hot plug events.  In this case, the documentation would become:

"To log on, insert your account key into the designated slot, after
removing any existing account keys from the terminal."

I think that's about as simple as it can be.

> Anyway, if this is really a feature to be on the system (as it seems to be 
> on a system with this sort of demonstrable properties between its 
> components), as this is a mechanism for everyone, it should be absolutely 
> usable, meaning that the information that it provides should flow as 
> fluently and clearly as possible.
>
> So... well, I think there's a need for a user interface expert here, unless 
> you think the proposed mechanisms so far are good enough. I'm *not sure* of 
> that (really, I don't think they're bad).

I agree with you that in the absence of special hardware or additional
policies, the protocol is a bit too complex.  However, I think that
there are readily simplifications available as soon as you talk about
a real world scenario.  For example, if you really have high security
requirements, then getting special hardware is a marginal cost.  If
you talk about personal desktops, the complexity is often reduced by
lowering the security requirements.

As long as we have strategies for all cases, and can make the common
cases simple, I am not overly worried if the corner cases are a tad
more complex (like, one extra keypress involved).

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]