[13585] in bugtraq
Future of s/key (Re: S/Key & OPIE Database Vulnerability)
daemon@ATHENA.MIT.EDU (Frasnelli, Dan)
Thu Jan 27 13:11:43 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.10.10001262134400.25099-100000@redshift.alphalinux.org>
Date: Wed, 26 Jan 2000 21:59:35 -0800
Reply-To: "Frasnelli, Dan" <dfrasnel@ALPHALINUX.ORG>
From: "Frasnelli, Dan" <dfrasnel@ALPHALINUX.ORG>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <14479.20641.518835.315870@hexadecimal.uoregon.edu>
> 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.
Discussing how one could displace the other is not logical -
ssh and s/key address two distinct security challenges.
ssh by itself provides advanced confidentiality and basic
authentication; s/key by itself provides advanced authentication
and no confidentiality. Suggesting ssh may replace s/key is
like saying "telnet might replace /bin/login".
The future of s/key is probably what it always has been: an otp
supplement to the basic Un*x password authentication, regardless
of what the access method (ssh, rsh, serial terminal) is.
Some sites I have worked with implement both:
- enforced rsa authentication for remote access via ssh
- s/key authentication for privileged account access.
No security technology or procedure is ultimately secure; it's just
a matter of time before l0pht cracks it.
Regards,
--
Dan Frasnelli
Security analyst
