Subject: Re: PaceSecurityServices & alternate algorithms

From: Ezra Cooper <[email-masked]>
Date: Tue, 6 Jul 2004 10:41:29 -0700

On Jul 5, 2004, at 4:54 AM, Greg Stein wrote:

> 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?

This sentence isn't totally clear to me, but I think it says either 
"demand that the user remember the hashed form of her familiar 
password" or "demand that the server use a certain algorithm to compute 
the stored version of the password."  But WSSE doesn't specify any 
particular hash algorithm, or provide an extensibility mechanism to 
pick one out at auth time, the way Digest does.

I want the user to be able to use her familiar password, and not the 
hashed version, of course.

Paul Hoffman wrote:

> The WSSE-like authentication mechanism as described earlier requires 
> that passwords be stored in the clear. It could be modified to allow 
> storage of a hashed form, I think. (I'm not sure here: we would need 
> to do some design and pass it by some applied crypto experts.)

This is essentially what I'm looking for, but it seems easier to use 
Digest than to modify WSSE.

Under Digest, the client can accept the familiar password from the 
user, and create the hashed form (according to a known algorithm named 
by the server), then prove to the server that it knows the hashed form.

This does have the weakness that if someone gets the hashed password 
off the server (which we assume a cracker can do, in a generic hosting 
environment), then he can authenticate himself to the server, because 
the hashed form is what would be used as the input to the Digest 
algorithm. The only advantage, then, is that the scope of the damage is 
limited, when we assume that the user has used that same password for 
other services. (Since the salt/realm would be different on other 
services, the hashed password would not be usable there).

Greg Stein wrote:

> 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.

Agreed. Still, I see it as valuable to keep cleartext passwords off the 
wire and out of the server's storage, and Digest allows us to do that.

>>   (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?
> [...]
> I can't see that introducing alternate algorithms will fix it, either.

The only reason to introduce alternate algorithms is to avoid a 
dependency on MD5. That might be valuable, because MD5 is (slightly) 
encumbered. I'm not hell-bent on this, but there may be some advantages 
to using SHA1 instead.

I'll defer to the community on whether MD5 should be required for all 
Atom tools (at least those that are not using SSL), or whether SHA1 
would be preferable.

> You aren't going to get around that unless you move to something more 
> akin to SSL

SSL solves all of the security problems, but it's not going to be 
feasible for many, many people who install downloadable software on a 
generic hosting account. I think this is a significant class of users 
that the community has chosen to keep in mind (correct me if I'm 
wrong).

I think SSL should be a 'standard option' for Atom auth since it does 
give more security and for those servers where it's possible, it's easy 
to set up.

Ezra