You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/09/29 20:20:35 UTC
Proposal for Win32 crypt() issue
I'd like to suggest the following workaround/solution to
the Win32 crypt() issue:
o Use MD5 on Win32.
o Modify htpasswd.c to take an additional switch to
indicate algorithm. Default is crypt, but #ifdef
so that on Win32 it says 'use -a md5 instead'.
o Likewise for dbmmanage. (?)
o For now, #ifdef the mod_auth* stuff to use MD5 on Win32.
(Ultimately this will be fixed by the reworked auth API.)
For the short term this makes Win32 and Unix .htpasswd
files non-interoperable. It would be nice to be able to
add a core directive that allowed the algorithm for a
particular scope/realm to be specified, but I don't
see that happening without a significant overhaul of
this stuff -- which is already slated for 2.0.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Proposal for Win32 crypt() issue
Posted by Marc Slemko <ma...@worldgate.com>.
What I'm wondering is if we can just provide a DLL that calls the md5
stuff, then people can replace that DLL with something that uses crypt if
they want.
If I understand it, there should be no export issues with having a hook to
crypt() that can be replaced by whatever code you want, since that API--by
definition--is one way. The problem is the crypt() code itself can have
internal entry points which results in it being usable for two-way.
On Tue, 29 Sep 1998, Ben Laurie wrote:
> Rodent of Unusual Size wrote:
> >
> > I'd like to suggest the following workaround/solution to
> > the Win32 crypt() issue:
> >
> > o Use MD5 on Win32.
> > o Modify htpasswd.c to take an additional switch to
> > indicate algorithm. Default is crypt, but #ifdef
> > so that on Win32 it says 'use -a md5 instead'.
> > o Likewise for dbmmanage. (?)
> > o For now, #ifdef the mod_auth* stuff to use MD5 on Win32.
> > (Ultimately this will be fixed by the reworked auth API.)
> >
> > For the short term this makes Win32 and Unix .htpasswd
> > files non-interoperable. It would be nice to be able to
> > add a core directive that allowed the algorithm for a
> > particular scope/realm to be specified, but I don't
> > see that happening without a significant overhaul of
> > this stuff -- which is already slated for 2.0.
>
> Sounds good to me - but why do anything more than provide an alternate
> crypt()?
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
> and Technical Director|Email: ben@algroup.co.uk |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
>
> WE'RE RECRUITING! http://www.aldigital.co.uk/
>
Re: Proposal for Win32 crypt() issue
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
>
> I'd like to suggest the following workaround/solution to
> the Win32 crypt() issue:
>
> o Use MD5 on Win32.
> o Modify htpasswd.c to take an additional switch to
> indicate algorithm. Default is crypt, but #ifdef
> so that on Win32 it says 'use -a md5 instead'.
> o Likewise for dbmmanage. (?)
> o For now, #ifdef the mod_auth* stuff to use MD5 on Win32.
> (Ultimately this will be fixed by the reworked auth API.)
>
> For the short term this makes Win32 and Unix .htpasswd
> files non-interoperable. It would be nice to be able to
> add a core directive that allowed the algorithm for a
> particular scope/realm to be specified, but I don't
> see that happening without a significant overhaul of
> this stuff -- which is already slated for 2.0.
Sounds good to me - but why do anything more than provide an alternate
crypt()?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/
Re: Proposal for Win32 crypt() issue
Posted by Ben Hyde <bh...@pobox.com>.
Rodent of Unusual Size writes:
>Marc Slemko wrote:
>>...
>For crying in your beer
Marc! Put down the beer!
Re: Proposal for Win32 crypt() issue
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 29 Sep 1998, Rodent of Unusual Size wrote:
> Marc Slemko wrote:
> >
> > You can have it use static storage if you pass in a NULL pointer.
>
> That doesn't help; you still need to link with libmain.
>
> For crying in your beer, it's only 24 bytes. And it's always
> 24 bytes, correct? Pass in a 24-byte buffer; palloc() it
> first if you want, but don't unnecessarily taint a G-P
> routine.
No, it does not take a 24-byte buffer. Passing it such would be broken on
systems where crypt() returns something longer than 24 bytes.
For example, this would break on FreeBSD using MD5 crypt.
Re: Proposal for Win32 crypt() issue
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Marc Slemko wrote:
>
> You can have it use static storage if you pass in a NULL pointer.
That doesn't help; you still need to link with libmain.
For crying in your beer, it's only 24 bytes. And it's always
24 bytes, correct? Pass in a 24-byte buffer; palloc() it
first if you want, but don't unnecessarily taint a G-P
routine.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: [PATCH] Take 1 (was: Proposal for Win32 crypt() issue)
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 29 Sep 1998, Rodent of Unusual Size wrote:
> Martin Kraemer wrote:
> >
> > Here's a first step at an "md5 crypt".
> >
> > * it takes a password and a "salt" (and uses the salt for
> > permutations)
> > * as Marc proposed in march, it takes a pool* to return a dynamic copy
>
> Unfortunately, that breaks its reusability in src/support/htpasswd.c.
> And elsewhere.
You can have it use static storage if you pass in a NULL pointer.
As to if you want to do that, that is a different matter.
Re: [PATCH] Take 1 (was: Proposal for Win32 crypt() issue)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Martin Kraemer wrote:
>
> Here's a first step at an "md5 crypt".
>
> * it takes a password and a "salt" (and uses the salt for
> permutations)
> * as Marc proposed in march, it takes a pool* to return a dynamic copy
Unfortunately, that breaks its reusability in src/support/htpasswd.c.
And elsewhere.
Before we start generating patches for multiple proposals, may
we come to a consensus about what we're going to do
strategy-wise?
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
[PATCH] Take 1 (was: Proposal for Win32 crypt() issue)
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Tue, Sep 29, 1998 at 03:40:14PM -0400, Jim Jagielski wrote:
> Rodent of Unusual Size wrote:
> >
> > I'd like to suggest the following workaround/solution to
> > the Win32 crypt() issue:
> >
> > o Use MD5 on Win32.
>
> I don't think having non-interoperable .htpasswd files is that big
> of a deal. I think this makes sense, esp for 1.3.3. :)
Here's a first step at an "md5 crypt".
* it takes a password and a "salt" (and uses the salt for permutations)
* as Marc proposed in march, it takes a pool* to return a dynamic copy
See Message-ID: <Pi...@valis.worldgate.com>
* it builds a base64 encoded result string (instead of simple hex),
giving a fairly similar look (to crypt()'s result), only the string is
24 bytes long instead of 13.
What's missing:
* optional integration into the various os.h files (right now, switching
to ap_crypt() instead of crypt() is done in the central ap_config.h
file)
* In mod_auth.c, the code must be rewritten to use ap_pcrypt() instead
of crypt() (as in Marc's version)
* The MSVC project files would have to be updated.
* I'm in a hurry. The #endif comments in the patch are wrong.
Ignore them for now.
These things are easy to add. Tell me if you want me to add these to the
patch.
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: Proposal for Win32 crypt() issue
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> I'd like to suggest the following workaround/solution to
> the Win32 crypt() issue:
>
> o Use MD5 on Win32.
> o Modify htpasswd.c to take an additional switch to
> indicate algorithm. Default is crypt, but #ifdef
> so that on Win32 it says 'use -a md5 instead'.
> o Likewise for dbmmanage. (?)
> o For now, #ifdef the mod_auth* stuff to use MD5 on Win32.
> (Ultimately this will be fixed by the reworked auth API.)
>
> For the short term this makes Win32 and Unix .htpasswd
> files non-interoperable. It would be nice to be able to
> add a core directive that allowed the algorithm for a
> particular scope/realm to be specified, but I don't
> see that happening without a significant overhaul of
> this stuff -- which is already slated for 2.0.
Why not go the OpenBSD/FreeBSD/Linux route and have the SALT argument
indicate the encryption method if more than one is available? In the case
of Win32 where only MD5 might be available by default that is the
algorithm you get regardless of the SALT. I don't see the need for an
additional switch here. And it isn't like an MD5 .htpasswd would be
completely non-interoperable. There are plenty of *BSD systems out there
where MD5 is the default encryption algorithm and in those case this file
would be completely interoprable if the same $1$ salt syntax was used.
See the crypt man page on any OpenBSD box, or the crypt() code in PHP3.
(http://cvs.php.net/cvsweb.cgi/functions/crypt.c?rev=HEAD)
-Rasmus