MD5

[Brian Behlendorf <br...@organic.com>]

On Tue, 2 Jan 1996, Alexei Kosut wrote:
> And, on another note... last week, I started looked into adding MD5 digest
> authentication to Apache, as per the current Internet Draft. (If anyone's
> working on this already, please speak up now and I'll stop looking). 
> However, the current auth code is decidedly not designed for use with
> multiple authentication types. One would have to write a mod_md5_auth and
> a mod_md5_auth_dbm and so forth and again for each additional auth type we
> want to support. So obviously we need a better way. Anyone have any
> thoughts on how this should be done? (the actual MD5 part seems easy, this
> would be the hard part). 

Well, you mean one would have to write a separate module for each 
(authenticationtype,passworddatabase) pair.  This actually isn't true - 
mod_auth and mod_dbm_auth *could* be combined, since they use different 
configuration options.  At least, I've never had a problem compiling with 
both turned on.  So, you could do a mod_auth_md5 and have config options 
for using either DBM files, flat files, or even mSQL in the same module.

Or am I missing something?

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Re: MD5

[Brian Behlendorf <br...@organic.com>]

On Sat, 6 Jan 1996, Alexei Kosut wrote:
> No, you're not missing anything. My point was that the auth modules are
> authentication-type-dependent. It'd be nice if one could write a module
> that did authentication without having to worry about authentication type
> - that should all be built into Apache, and the modules should have some
> generic functions to call that will work with any authentication scheme, 
> so we don't need different versions of the modules for each type. This is 
> especially important if we want to support some kind of security 
> negotiation in the future.
>
> Doesn't that make sense?

Well, no.  MD5 authentication is not just a "better way of sending passwords"
- at least my understanding is that there are differences in the way names
are managed.  What I guess you're suggesting is there there be an API between
the machinery that handles the authentication-HTTP, and the machinery that
looks up or stores a password.  Sorta like ODBC, a way of describing
operations on a database which isn't database-dependent.  So then you could
write your MD5 module and it would automagically work with msql. 

Yeah, that would be nice. 

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Re: MD5

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Sat, 6 Jan 1996, Brian Behlendorf wrote:

> Well, you mean one would have to write a separate module for each 
> (authenticationtype,passworddatabase) pair.  This actually isn't true - 
> mod_auth and mod_dbm_auth *could* be combined, since they use different 
> configuration options.  At least, I've never had a problem compiling with 
> both turned on.  So, you could do a mod_auth_md5 and have config options 
> for using either DBM files, flat files, or even mSQL in the same module.
> 
> Or am I missing something?

No, you're not missing anything. My point was that the auth modules are
authentication-type-dependent. It'd be nice if one could write a module
that did authentication without having to worry about authentication type
- that should all be built into Apache, and the modules should have some
generic functions to call that will work with any authentication scheme, 
so we don't need different versions of the modules for each type. This is 
especially important if we want to support some kind of security 
negotiation in the future.

Doesn't that make sense?

--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------