Re: S/Key & OPIE Database Vulnerability

[merlin () SCL CWRU EDU (Brandon Palmer)]

> Initially I thought this meant removing the seed entirely from S/Key.
> Mudge clarified this to me by explaining that what he meant was removing
> the routine presentation of the seed in the login challenge, but
> continuing to use it internally.  It would still be necessary to present
> a new seed in the process of renewing one's S/Key sequence, so while the
> seed is still exposed, the amount of repeat exposure would be
> significantly reduced.  This is at least quite a bit better than what I
> thought he meant before.

There are some pros and cons to removing the seed.  Consider if we were to
remove it.  In this case,  we would need to be there when we renew the
keys.  The renewing process would then tell us what our seed is and we
could record this.  (in a palm pilot,  for example).  The danger in this
is if we lose the key.  I presume you could have a function that would
tell you,  but if you are not on the machine,  that won't work.  I am in
favor of the more secure option,  but it may not fit the needs of all.

> Ultimately I wonder how much of a future S/Key has now that SSH and
> similar utilities are widely deployed and provide much more
> sophisticated protections, especially session encryption.

I think there is definatly still a need.  There are many cases in which I
am not on a machine what has ssh (ie some public telnet shell).  Though
the session is not encrypted,  my password is still safe.  Until ssh-java
shells are common,  s/key still has it's place.

- merlin

SCL Manager, CWRU
b () scl cwru edu 216.368.5066
pgp key: clabs.cwru.edu/b.pgp