httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Constable <ma...@renta.net>
Subject Re: Patch for mod_authn_dbd plaintext auth
Date Sat, 09 Jun 2007 07:39:11 GMT
On Saturday 09 June 2007 06:32:12 Nick Kew wrote:
> [ it's a bit off-topic in modules-dev.  dev@httpd is where
> we discuss proposals for changes to httpd.  Or if you have
> no such ambition but just want to share a patch, somewhere
> on the web is better than a mailinglist.  A traditional
> way to do this is in bugzilla, though the wiki-faq might
> be a better solution now that it's available.]

Apologies. I assumed this was a list to discuss modules
for apache.

> Tip: what is the problem you're fixing?

I want apache to be able to do basic auth against any
SQL database that contains plain text passwords.

> You want to store plaintext passwords, that's your business.
> But why are plaintext passwords in SQL any different to
> plaintext passwords in, say, a DBM or flat file?

I just happened to hack my way thru this patch where
I particularly need it to work, mainly with sqlite. I
suspect no one else would want plain text passwords in
.htaccess files. I don't.

> An equivalent patch in mod_auth_basic would apply not just
> to passwords stored in SQL, but to passwords anywhere.

Obviously a matter of consensus if it was needed higher
up the module chain.

> Should we do that?  Well, the case for it goes something
> like "We should support storing passwords in plaintext
> because [... make your case here ...]".  If you convince
> people it adds value, then maybe we'll adopt it.

I use a common database for ftp, smtp, pop, imap and radius
dialup/adsl authentication and it *must* contain plaintext
passwords for RADIUS CHAP auth and SMTP auth (courier-mta).

Also, as an ISP, with 1000s of clients and limited support
staff, being able to view a clients login password and advise
that client (often via phone) what it is makes our lives much
easier than having to advise the client how to reset their
password in 1/2 dozen applications (far too time consuming).
There is no way we would go back to using encrypted passwords,
even if we could, the convenience factor is just too high.

I could add an extra otherwise redundant crypted password
field to my common database, just for web auth, or, hack on
apache until I don't need that otherwise redundant field.

I personally think it's a valid option to provide and I lean
towards thinking it only applies to the DBD level. A crypted
(or better) password hash in a plain text .htaccess is a good
idea but a database is already a binary blob so both would
prevent trivial accidental viewing of passwords. Neither of
them, even with encrypted passwords in the database, would
stop a dedicated hacker *if* security was of the utmost of
importance.

I would like to think the server admin should have choice of
whether the passwords stored in a database (and/or elsewhere)
are either plaintext or encrypted in some manner. None of the
other services I provide deny me the use of plaintext passwords.

--markc

Mime
View raw message