by redmail.netbsd.org with SMTP; 31 Jan 2000 02:21:57 -0000
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <woods@most.weird.com>) 
	id <m12F6TJ-000g5rC@most.weird.com>
	for tech-security@netbsd.org; Sun, 30 Jan 2000 21:21:45 -0500 (EST)
	(Smail-3.2.0.110-Pre 1999-Oct-27 #5 built 2000-Jan-29)
Message-Id: <m12F6TJ-000g5rC@most.weird.com>
Date: Sun, 30 Jan 2000 21:21:45 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@most.weird.com (Greg A. Woods)
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
In-Reply-To: <20000130142347.A20452@noc.untraceable.net>
References: <m12EylK-000g6HC@most.weird.com>
	<10352.949256944@munnari.OZ.AU>
	<20000130142347.A20452@noc.untraceable.net>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada

[ On Sunday, January 30, 2000 at 14:23:47 (-0500), Andrew Brown wrote: ]
> Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
>
> [ On Monday, January 31, 2000 at 05:29:04 (+1100), Robert Elz wrote: ]
> > 
> > Is it?   Maybe I read about it elsewhere.

The documentation only says [from skey(1)]:

     S/Key uses 64 bits of information, transformed by the MD4 algorithm into
     6 English words.  The user supplies the words to authenticate himself to
     programs like login(1) or ftpd(8).

but that didn't explain to me what was in /etc/skeykeys -- all I
understood was that's how the "6 English words" were derived, presumably
from the secret and the challenge.

> > Its a simple one time hash on the seed and the secret, performed
> > N times.   Each time it is used the result replaces the known hash
> > (in skeykeys) and N-1 is used next time.   This relies upon the
> > uninvertability (if there is such a work) of the hash.  MD5 (or sometimes
> > MD4) is used as the hash function - it is believed to be hard to invert.
> > That is, it is easy to go from secret to hash(secret)^N, but very
> > hard to get from hash(secret)^N to hash(secret)^(N-1).
> > 
> >[[....]]
> > 
> > As it is here - but the seed is the secret, only you know that (in theory).
> > The skeykeys file is just like the traditional unix passwd file, and only
> > stores the hashed value (the N times hasshed value, then after that is
> > used once, the N-1 times hashed value).
> 
> yep.  the file has your hash for the count of n and asks you for the
> has of n-1.  then it computes (via one round in md4) the hash that it
> currently has stored, and if they match it writes the new n-1 value
> and lets you in.

Thanks guys for (re)explaining this to me.

It makes me feel a little bit better than I once did about S/Key & OPIE.

However I think the documentation needs a bit of work as it would seem
to me that it is incredibly important to change either the seed or one's
"secret password" every time one runs skeyinit.  At the moment the code
doesn't even change the seed unless it ends in a digit, never mind check
to see if the same seed is being reused.  Wouldn't it be better to try
and pick a much more random value every time?  Wouldn't it also be
better to include more information specific to the host in the default
seed too (can the seed be made longer -- the docs don't say but the code
has the magic numbers "18" and "17")?  Shouldn't there be explicit
warnings about never distributing /etc/skeykeys to other hosts?  (The
latter is probably what happened on the one network where the
challenge/response pairs for "root" were always the same on each host.)
Shouldn't there be warnings about never using the same seed and secret
on multiple hosts and always watching for the same

I wonder if the default algorithm of "just add one" used to adjust the
seed makes the subsequent set of responses predictable in any way
(i.e. even without knowing the secret password)....  Is this maybe what
the posting on BUGTRAQ was worried about?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>