Subject: [http-auth] Modifications to Basic & Digest

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Jul 2014 11:24:02 -0400

Hi

A question we raised at the HTTP-Auth meeting today was whether or not we’d like to make any changes to Basic and Digest.

The charter requires us to add to things to these protocols:
Adding internationalization support for user names and passwords
Adding modern hash functions to Digest so that an implementation does not depend on MD5.

There are a few additional extensions proposed. The Digest draft includes optional username hashing, which (when used) will prevent the cleartext username from being sent on the wire. This sounds (to me) to be a good idea privacy-wise, but there is a claim that Basic and Digest are so horribly broken anyway, that we don’t want to add security features to them, even if said security features seem like a good idea (hence the “lipstick on a pig” comment I made at the session [1]).

So the question I’m asking the group here is, do we want to tinker with Basic and Digest, potentially making them somewhat better, or do we want to clamp down on all such discussion, and stick only to the mandates in the charter?

Yoav

[1]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Jul 2014 09:49:34 -0700

> There are a few additional extensions proposed. The Digest draft includes optional username hashing, which (when used) will prevent the cleartext username from being sent on the wire. This sounds (…

Yeah, that's what they said in 1994.  Look how well that worked out.

> So the question I’m asking the group here is, do we want to tinker with Basic and Digest, potentially making them somewhat better, or do we want to clamp down on all such discussion, and stick only…

Basic could be easily extended by optionally replacing the cleartext
credentials with a prefix and one-time hash, where the prefix indicates
how to compute the hash.  It makes no difference to the wire protocol
other than a server indication that it implements the extension.
This is essentially how OTP works in Basic, though OTP relies on users
knowing how to generate the "hash" each time.

Digest could be easily extended so that the hash-of-hashed password form
doesn't require the server to maintain session state.

Neither improvement achieves perfect security, but they would help.

....Roy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Jul 2014 23:25:01 +0100

I'd also be interested in whether or not these changes might impact
on the liklihood of the updated versions being implemented.

I don't know if they would or not, and of course we can't know for
sure, but it'd be interesting to know something about that if its
knowable. That is, if commenting on these, it'd be useful to say if
you're an implementer and would implement 'em.

S.

On 24/07/14 16:24, Yoav Nir wrote:
>  1. Adding internationalization support for user names and passwords
>  2. Adding modern hash functions to Digest so that an implementation does not
>     depend on MD5.
> 
> 
> There are a few additional extensions proposed. The Digest draft includes 
> optional username hashing, which (when used) will prevent the cleartext username 
> from being sent on the wire. This sounds (to me) to be a good idea privacy-wise, 
> but there is a claim that Basic and Digest are so horribly broken anyway, that 
> we don’t want to add security features to them, even if said security features 
> seem like a good idea (hence the “lipstick on a pig” comment I made at the 
> session [1]).
> 
> So the question I’m asking the group here is, do we want to tinker with Basic 
> and Digest, potentially making them somewhat better, or do we want to clamp down 
> on all such discussion, and stick only to the mandates in the charter?
> 
> Yoav
> 
> [1]
> lipstick_pig_080910_mn1.jpg
> 
> 
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 24 Jul 2014 22:37:04 -0400

Thanks Roy,

> doesn't require the server to maintain session state.
I am not clear on what you mean by "hash-of-hashed password form..."; can
you please elaborate?
The current recommendation in the draft calls for the following operation
to protect the username: H(username:realm) as defined in section 3.4.4.

Regards,
 Rifaat

On Thu, Jul 24, 2014 at 12:49 PM, Roy T. Fielding <[email-masked]> wrote:

> A question we raised at the HTTP-Auth meeting today was whether or not
> we'd like to make any changes to Basic and Digest.
>
>    2. Adding modern hash functions to Digest so that an implementation
>    does not depend on MD5.
>
>
> optional username hashing, which (when used) will prevent the cleartext
> username from being sent on the wire. This sounds (to me) to be a good idea
> privacy-wise, but there is a claim that Basic and Digest are so horribly
> broken anyway, that we don't want to add security features to them, even if
> said security features seem like a good idea (hence the "lipstick on a pig"
> comment I made at the session [1]).
>
>
> So the question I'm asking the group here is, do we want to tinker with
> Basic and Digest, potentially making them somewhat better, or do we want to
> clamp down on all such discussion, and stick only to the mandates in the
> charter?
>
>

---

From: Tim <[email-masked]>
Date: Fri, 25 Jul 2014 09:29:14 -0700

> you're an implementer and would implement 'em.

In the case of Digest auth, I'd just be happy if major browsers
actually implemented it consistently.  There have been issues in the
past with lack of clarity in the original RFC that created
incompatibilities.  That and some browsers don't bother to implement
significant chunks of the protocol.

Perhaps just more clarifications to the RFC on how it should work
would be in order.

As far as extending Digest further, I think it actually has some
flexibility to be extended through the opaque value that is included
in the hash.  One could plausibly put all kinds of ciphertext in there
to pass useful information around between clients, servers and even
third-party servers (think SSO).  So if Digest were just implemented
consistently, one could imagine more advanced extensions that don't
break RFC compliance...

tim

PS- Everything I just said is based on fuzzy memories of when i delved
into this over a year ago, so I may be off on some details.

---

From: Sophie Bremer <[email-masked]>
Date: Fri, 25 Jul 2014 19:31:14 +0200

Hello,

we already use Digest with username hashing in two apps for iOS and OS X since February. And we like to implement it in the browser front end by next year. We use username hashing to protect email addresses in case of TLS blocking by a great firewall.
If we implement it in all applications and browser front ends, it will impact about a million users.

Best regards,
Sophie

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Jul 2014 11:56:16 -0700

On Jul 24, 2014, at 7:37 PM, Rifaat Shekh-Yusef wrote:

> I am not clear on what you mean by "hash-of-hashed password form..."; can you please elaborate?

Never mind -- I misremembered how A1 is calculated in both cases.

I would prefer to have a version of A1 that allows the client to provide
a salted hashed origin-unique password to the server.  However, on second
thought, this might be better done with an extension that is independent
of the authentication scheme, since the result is just another opaque
password string, or with a new authentication scheme.

....Roy