Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id PAA00927; Fri, 15 Aug 1997 15:56:29 -0700 (PDT) Received: from veal.organic.com (h20.n145.organic.com [204.152.145.20]) by hyperreal.org (8.8.5/8.8.5) with ESMTP id PAA00915 for ; Fri, 15 Aug 1997 15:56:25 -0700 (PDT) Received: from localhost (akosut@localhost) by veal.organic.com (8.8.3/8.6.12) with SMTP id PAA00757 for ; Fri, 15 Aug 1997 15:56:19 -0700 (PDT) X-Authentication-Warning: veal.organic.com: akosut owned process doing -bs Date: Fri, 15 Aug 1997 15:56:17 -0700 (PDT) From: Alexei Kosut To: new-httpd@apache.org Subject: Re: Apache 1.3a1 Authentification (re) (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Fri, 15 Aug 1997, Paul Sutton wrote: > The point with Unix crypt() is that you can (a) publish the source doe and > (b) make the salt (key) readily available and it is *still* a one-way > function. That is you can never get the original back, even with full > knowledge. So no-one can ever decrypt your Unix password (of course, they > can try encrypting and comparing, like crack does, but that is another > matter). With the NT encryption calls, unless I am missing something, > anyone can take your encrypted htpasswd file and keys onto a new system, > write a program to call the decrypt() function and get your passwords. I > would guess this is an aceptable level of security for NT systems. I suspect there's something that can be done. What if you encrypted the password, using the password itself as the key. Then you couldn't unencyrpt it to find the password unless you knew it already. When you got a password, you'd encrypt that with itself, and see if it matched your already-encrypted password. It's reverse of the way Unix crypt() does it, but I think that would work. -- Alexei Kosut