[13596] in bugtraq
Re: Future of s/key (Re: S/Key & OPIE Database Vulnerability)
daemon@ATHENA.MIT.EDU (der Mouse)
Fri Jan 28 13:46:44 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <200001272123.QAA01088@Twig.Rodents.Montreal.QC.CA>
Date: Thu, 27 Jan 2000 16:23:58 -0500
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
> The future of s/key is probably what it always has been: an otp
> supplement [...] regardless of [] the access method
It's always seemed to me that s/key's biggest problem is that it's
*not* a true one-time password scheme: the passwords are
algorithmically related. Indeed, I believe it's no coincidence that
all the attacks against s/key (that I've heard of) are based on just
this weakness. It's very much like the difference between a
conventional stream cipher and a one-time pad, actually.
Of course, a true one-time password scheme (where "true" here means
that the passwords are truly random and completely unrelated) has its
own problems, mostly related to storing the passwords in question.
Personally, I generate passwords by rolling dice[%] and store them on a
small pad of paper (which I carry on my person when I travel) - not
entirely unlike a one-time pad. :-)
[%] And running the result through a simple hash function - more
precisely, I generate entropy by rolling dice and generate
passwords from that entropy by a simple encoding scheme.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
