Re: PaceSecurityServices & Digest auth

[Greg Stein <gstein@xxxxxxxxxx>]

On Wed, Jun 30, 2004 at 06:44:40PM -0700, Ezra Cooper wrote:
>...
> I see three issues to be addressed with Digest:
> 
>   (1) Some web-servers remove the WWW-Authenticate header before 
> passing it to a CGI program.

This is on purpose. Very, very much so.

The mechanism for passing information from the web server to the CGI
program is via the environment. The particular scenario that you're trying
to solve is "my ISP let's me write a CGI, and I can't enable authn within
the web server itself [so I must do authn in the CGI script]".

Now carry this forward a couple steps. In some environments, suExec is
being used so the script runs as the user who wrote the thing. But in some
environments, the CGI runs as the same user as the httpd process. Or, in
other words, *all* CGI scripts run that way.

Now you've got a bunch of CGI scripts all running as the same uid, and
you've got some authn information sitting in the environment of some. Now
some cracker comes along and simply dumps out /proc/*/environ from his own
CGI. Sure, many can't be read, but some *can*. And now he has your
password.

Apache does not pass the Authorization header to CGIs because it is a
security hole. A big one. You can enable it if you want, but you're going
to have to pass -DSECURITY_HOLD_PASS_AUTHORIZATION to the Apache build.
That symbol isn't a joke. It really is a hole if that goes into the env.

>   (2) We need an equivalent method for use within a SOAP message.
>   (3) The default HTTP Digest auth algorithm is based on MD5, and 
> requires the server to be able to form an MD5 hash based on the triple 
> (username, realm, password). If you don't store either the cleartext 
> password or that specific hash, you're out of luck.

"or that specific hash" seems to solve the problem just fine. What's the
issue here?

> To address (1), I propose this addition to the end of section K,kk. in 
> PaceSecurityServices:
> 
> ========
> An Atom client MAY authenticate itself to an Atom server by sending an 
> X-Atom-Authenticate HTTP header, in the same form as for the 
> WWW-Authenticate header [RFC2617]. If an Atom client sends a 
> WWW-Authenticate header, it SHOULD have the same value as the 
> X-Atom-Authenticate header.
> ========

This simply introduces a security hole, which is not something we should
be advocating or encouraging. I'll -1 this right now. And if I'm feeling
particularly evil, I'll go update the httpd server to filter this header,
too (big <wink>!)

>...
> As to (2), I suggest that we simply tunnel the header fields of HTTP 
> Digest Auth within XML elements (the same way we've done with WSSE). 
> Using WSSE UsernameToken is attractive, except for requiring the server 
> to store the password in the clear. I'll be interested what others 
> think about this.

Why not just use WSSE? Above, you take issue with storing cleartext digest
passwords. Can't you just use WSSE and demand that the hashed-form of that
authn mechanism be used?

> To address the third issue, I'd like to propose some alternative 
> "algorithms" (in the sense of RFC 2617) for Digest auth. In particular

The server should just store the hashed forms. I don't see a big problem
here.

I can't see that introducing alternate algorithms will fix it, either.
Digest authn has a basic structural weakness (to exposure of the
server-side cleartext passwords or hashes) because of how (and what)
information is traded between server and client. You aren't going to get
around that unless you move to something more akin to SSL (and hashing
arbitrary values, rather than just coughing up a particular hash result).


IMO, use SSL. Failing that, use Digest. Failing that, use WSSE with a
hashed secret (no plaintext!). I don't know that Yet Another
Authentication Mechanism needs to be defined.

Cheers,
-g