Digest Auth driving me nuts!!!

Hi guys,

got a problem with digest auth. - did everything by the book + tried
every possible suggestion I could find on the net - nothing.

What I'm trying to do is very simple - I have a directory in my
DocumentRoot which I want to password-protect, so:

<Directory "C:/MySite/Protected/">
AuthType Digest
AuthName "Private"
AuthDigestFile /bin/passwords
Require user ron
</Directory>

and using htdigest:

htdigest -c passwords private ron

now, everytime I try to access the folder my username and/or password
are not accepted.

any ideas, oh experienced ones?

Windows XP SP2
Apache 2.0.55
PHP 5.1.1

On Fri, 20 Jan 2006 18:03:26 -0800, Ronson sent:

> got a problem with digest auth. - did everything by the book + tried every
> possible suggestion I could find on the net - nothing.
>
> <Directory "C:/MySite/Protected/">

The manual states you shouldn't end directory directives with a slash.

> AuthDigestFile /bin/passwords

You're storing passwords in your /bin directory?!?!? Apart from the fact
you shouldn't be putting things that aren't binary executables in there,
the /bin directory is readable by everybody.

> Windows XP SP2
> Apache 2.0.55
> PHP 5.1.1

But which browser? If you installed the docs with your server, look at:
<http://localhost/manual/howto/auth.html>, otherwise go to the Apache
website. It mentions that *that* method of authentication isn't widely
supported in clients.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

"Ronson" <ronroze@gmail.com> writes:
> any ideas, oh experienced ones?

Digest auth never really caught on. If you're concerned about
passwords getting sniffed with basic auth, the preferred solution is
enable SSL and let the application check the password. Digest auth
isn't all that great. SSL prevents exposing the hashed password to
offline dictionary search, and checking passwords in the application
means you can do things like temporarily lock out the user account
after too many wrong password guesses. Most http authentication
modules (whether digest or basic) don't bother with such precautions.

Paul Rubin wrote:
> "Ronson" <ronroze@gmail.com> writes:
>
>>any ideas, oh experienced ones?
>
>
> Digest auth never really caught on. If you're concerned about
> passwords getting sniffed with basic auth, the preferred solution is
> enable SSL and let the application check the password. Digest auth
> isn't all that great. SSL prevents exposing the hashed password to
> offline dictionary search, and checking passwords in the application
> means you can do things like temporarily lock out the user account
> after too many wrong password guesses. Most http authentication
> modules (whether digest or basic) don't bother with such precautions.


I'm sorry to say that I disagree on this suggestion. Of course using SSL
hides the password but it also hides all content and that may not
neccesarily be a good thing because it negates any performance
optimization possible through intelligent web caching.
After HTTP 1.1 standard was finalized and digest auth became available
we've been constantly trying to force vendors to accept this standard,
alas with varying success. Having Apache supporting digest auth as a
reference implementation is therefore very important.

With regards to the lock-out issue I believe this should be handled by a
Web server authentication plugin and not by the application. Use of
software like Oracle/Oblix Netpoint Access Mgr or Sun Access Mgr.
isolates the authentication from the application and ensures consistent
lock out and password policies throughout all your web applications. I
believe this could also be performed by native LDAP plugin for Apache.

Per W.
Hydro IS Partner

Per Weisteen <per.weisteen@hydro.com> writes:
> I'm sorry to say that I disagree on this suggestion. Of course using
> SSL hides the password but it also hides all content and that may not
> neccesarily be a good thing because it negates any performance
> optimization possible through intelligent web caching.

If you look at ebay, hotmail, etc., when you log in, the form
submission goes to an SSL target page so your password is encrypted.
The target page sets an authentication cookie and redirects you to a
normal http page, and you then surf around using normal http. So you
get all that caching and stuff except for the page that actually sees
your password. Of course someone might intercept the cookie and
re-use it, but it should have a timeout. You can think of obvious
ways to referesh a timed-out cookie by setting a second cookie through
SSL and redirecting to a page that checks the SSL cookie if the
non-SSL cookie is timed out.