From owner-freebsd-security Mon Jun 3 15:46:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24596 for security-outgoing; Mon, 3 Jun 1996 15:46:21 -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 PAA24576 for ; Mon, 3 Jun 1996 15:46:15 -0700 (PDT) Received: (from nobody@localhost) by ns1.zygaena.com (8.7.5/8.7.3) id SAA08853; Mon, 3 Jun 1996 18:46:16 -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 sma008851; Mon Jun 3 18:45:53 1996 Received: (from ewb@localhost) by selway.i.com (8.7.3/8.7.3) id SAA02583; Mon, 3 Jun 1996 18:45:36 -0400 (EDT) Date: Mon, 3 Jun 1996 18:45:36 -0400 (EDT) From: Will Brown Message-Id: <199606032245.SAA02583@selway.i.com> To: angio@aros.net, karpen@sea.campus.luth.se Cc: freebsd-security@freebsd.org Subject: Re: MD5 Crack code Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dave Andersen said: > SecurID is a challenge/response one-time authentication system. You > log on, the system tells you the challenge, you enter the challenge in to > your SecurID calculator along with your calculator password, the calc. > hands you back a response, you type the response in, you're authenticated. > Good stuff for high-security applications. I thought the Security Dynamics card had only an LCD display and no keyboard. It generates a new password every minute. That plus a PIN are used to gain access. So you have to HAVE the card and KNOW the PIN - two factors. Exactly how it stays in time-sync with servers I don't know. Maybe there is more to it... (speak up folks). Yes unfortunately the target customer seems to be high-end security freaks (with $$), not ISPs and the ilk (sigh). This IS a quite accurate description of Skey though, except the "calculator" is a software application (with a resulting reduction in security). Has anyone built a credit-card SKey calculator? >> Why not simply something like SSL which is being developed and used a lot >> just because the WWW is growing with enormous speed? If you have a secure >> link, there is no need for a lot of hassle. You can send anything over the >> socket and it'll be safe. Umm.. No? IF there were SSL-enabled client applications such as FTP, telnet, POP/IMAP mail programs for *all* platforms (well, windoze, 95, NT, and MAC ) and not just for unix then that'd be great (Dave's comments below withstanding). But, the certificate issue and patent issues and legal issues associated with crypto solutions are real problems. I'm hunting for a real-today, practical password protection system, Not the be-all, end-all solution to all privacy and authentication issues. > There's still a difference between a one-time password system and a > constant password, and for security reasons, the one-time system is > preferable if you can abide by the inconvenience of having to use it. > Even if life is encrypted, there's always the off chance that someone > could: > a) steal the original password (social enginnering, actual theft, > hacking the password file) > b) Use some form of playback attack against the system, because the > password doesn't change. Yes, the encryption does, but it's one > more level of security. > > For best results, add water, and let rest for twenty minutes. Use both > encryption and a one-time password scheme. > > -Dave Andersen Skey (which is a one-time password scheme based on MD4) provides ONLY for authentication, not privacy. FreeBSD login already supports it BTW. I view it as weaker than a strong encryption approach but it has some big plusses - it is *not* crypto, so there are no Big Brother restrictions on its use in the Land of the Free (correct me if I'm wrong net.lawyers), and its a LOT simpler, AND it doesn't have to be inconvenient. If Skey's client side was implemented within the clients rather than as a separate calculator application (or hardware) then the clients would be no harder to use than they are now (login: password:) but the passwords would never be transmitted (in fact it would be safe to use one password for multiple servers, and there is nothing extra to remember). To be painfully pedantic, an FTP client (say) with Skey knowledge would observe the challenge (as opposed to normal login:), request the secret seed password from the user (user sees "password:") generate the one-time password using this info and complete the authentication. To the user it looks EXACTLY like a "normal" login. The problem is that there are no Skey clients, just as there are no SSL (or other crypto) clients, for all platforms. I think it would be a lot easier to build the Skey clients then the crypto clients. So why am I not doing it? Thought I'd see if anyone had already, or was contemplating doing so, or could be coerced into it first :) Actually, because re-inventing CuteFTP (eg) just to put in Skey seems silly. More practical to try and get client authors to incorporate Skey. IMHO that simple step away from cleartext passwords would be a big step forward for internet security. ------------------------============================----------------------- 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