From owner-freebsd-security Fri Jun 7 07:05:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17011 for security-outgoing; Fri, 7 Jun 1996 07:05:16 -0700 (PDT) Received: from ns1.zygaena.com (ns1.zygaena.com [206.148.80.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA17000 for ; Fri, 7 Jun 1996 07:05:11 -0700 (PDT) Received: (from nobody@localhost) by ns1.zygaena.com (8.7.5/8.7.3) id KAA24788; Fri, 7 Jun 1996 10:05:07 -0400 (EDT) X-Authentication-Warning: ns1.zygaena.com: nobody set sender to using -f Received: from selway.i.com(198.30.169.1) by ns1.zygaena.com via smap (V1.3) id sma024783; Fri Jun 7 10:04:56 1996 Received: (from ewb@localhost) by selway.i.com (8.7.3/8.7.3) id KAA02891; Fri, 7 Jun 1996 10:04:52 -0400 (EDT) Date: Fri, 7 Jun 1996 10:04:52 -0400 (EDT) From: Will Brown Message-Id: <199606071404.KAA02891@selway.i.com> To: pst@shockwave.com Cc: freebsd-security@FreeBSD.org Subject: s/key and OTP [was: MD5 Crack code] Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Paul Traina wrote: > I'd like opinions from folks about the switch to OTP. It's where > we "should" be going, but there are a lot of utilities out there > (such as Fetch for the Macintosh and our own tools) that finally > understand and handle s/key properly, as well as windows/macos > s/key calculators, and I really don't want to pull the rug out from > under anyone. IF s/key is approaching "defacto standardization" then that process should be allowed to continue and OTP should go away. IMHO it is more important that a standard be established and rolled into the *many* different clients on multiple platforms, then to address the minor nits of the standard and thereby delay the arrival of any form of one-time password security. I will withdraw MHO if anyone points out an uncorrectable fatal flaw in s/key that is being addressed by OTP. Ok, md4 may not be as strong as md5, but it is so much better than cleartext that I'd rather have s/key now, then something slightly better N years from now. I like to keep in mind that none of the cryptographic algorithms based on NP hard or NP complete problems are proven secure. And that even if they were, flaws in implementations seem to be nearly impossible to prevent. Not to mention all the other potential ways to crack systems (Crack, social engineering, dumpster diving,...). These facts largely defeat arguments that one algorithm is much "better" than another, esp. as we desparately need to get away from cleartext passwords now. ------------------------============================----------------------- Will Brown ewb@zns.net Professional Web Design Zygaena Network Services http://www.zns.net and Hosting 216-381-6019 (voice) 216-381-6064 (fax) at reasonable prices