httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: basic auth broken
Date Sun, 31 Jan 1999 23:34:00 GMT
On Sun, 31 Jan 1999, Rasmus Lerdorf wrote:

> > You have to do it at run time, not compile time.  The normal way of
> > switching between crypts on FreeBSD is to change the link for libcrypt to
> > the md5 or DES one.  Both binary packages and people who change this
> > would be broken by a compile time check.  
> > 
> > We have to remember that the whole point of this is to make our md5 
> > passwords work on any Apache installation on any platform, plus make
> > the native ones work on that particular platform.
> But, these various crypt() implementations on the different operating
> systems all have different capabilities.  You can for example have a
> password file with DES, MD5 and Blowfish encrypted passwords all
> intermingled and working perfectly on OpenBSD.  On most FreeBSD and Linux
> boxes you can have DES and MD5 strings in the same file.

That doesn't matter.  The only thing we need to care about it using the
native crypt() or our md5 passwords.  The reason we need our md5 is for
win32, and it has the nice side effect of letting people generate
portable passwd files if they want.  

It doesn't matter if our md5 matches any other platform or not, but we
need some way to tell if a password is our md5 or native.

> What I was trying to say in my other post (vaguely I guess) is that we
> should be using crypt() directly instead of ap_MD5Encode() to generate the
> MD5'ed password.  

We can't do that.  The whole point is we need a portable format.  I don't
see any need for us to go crazy with a zillion ways, just native and our

The only reason for making it compatible with FreeBSD's native md5, is
then we can perhaps make the assumption that "$1$" == do_it_this_way,
because FreeBSD already has the "$1$" id well defined. 

If we don't do that, then we need to make up our own identifier and do all
the stuff necessary to ensure we don't have conflicts, etc.

This is necessary so we can transparently use a passwd file that uses
either the native crypt or our md5 stuff.  As I already mentioned, the
other option is to require that the user specify which format it should

> And I don't think we can have it both ways.  We can't both create passwd
> files that are cross-platform and also ensure that they work natively.  If

That isn't what we care about.  We care about being able to make a passwd
file that will work on any platform, _or_ making one that will work on the
native platform.  Now, that portable format may be the native format
sometimes and vice versa, but that is just a side effect.

View raw message