apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: apr_password_validate on win32 silently mishandles crypted hashes
Date Thu, 27 May 2004 13:38:37 GMT

> This should move to the httpd list

um, ok, but it's not necessarily a .htpasswd specific issue.  anyone trying
to use apr_password_validate on win32 could potentially run into this.

the snag, as I see it, is that the fallback position on systems with crypt
is crypt, while the fallback for systems that don't understand crypt is a
simple string comparison.  I think that is incredibly misleading for users
of those latter platforms - it goes beyond the simple platform nuances we
all accept and into "oh, no!  that's not what I wanted!"

since the comment for the function is currently

  * Validate any password encypted with any algorithm that APR understands

and APR currently doesn't understand crypt for win32, then I would suggest
that it is better to return APR_EMISMATCH outright.  if people wanted a
simple string match they could do it themselves, right?

anyway, I'm just saying (as someone unfamiliar with the history here :) that
I'm surprised the current behavior is considered desirable.

> , but since I wrote this code originally
> for 1.3, I'll just answer it here.  Apache on Windows doesn't support
> .htpasswd files that were generated on Unix using crypt().  It never has.
> Yes, if you try to use it, and send the crypt() encoded password, it will
> succeed.  But, that just doesn't happen in practice.  

ok, it's unsupported behavior in httpd-land.  but there is a difference
between "not supported" and "oh, by the way, we let invalid passwords
succeed when they shouldn't," especially when it seems such an easy thing to
get right.

but I've said my piece now, so I'll leave it alone.  those with apr karma
are in charge.

--Geoff

Mime
View raw message