Subject: [http-auth] New Proposal For Hashed Username

From: Sophie Bremer <[email-masked]>
Date: Sat, 21 Dec 2013 16:51:08 +0100

Here is a new proposal for hashed usernames, that is backward compatible.

1 Implementation

1.1 WWW-Authentication Response Header

  If the server likes to receive the username as a hashed value, a
  userhash key with the value of "true" is sent in the
  WWW-Authentication header.

     digest-challenge  = 1#( realm | ... | nonce | ... | [userhash] )
     nonce             = "nonce" "=" nonce-value
     nonce-value       = quoted-string
     userhash          = "userhash" "=" ( "true" | "false" )

1.2 Authorization Request Header

  If the client supports username as a hashed value, a userhash key
  with the value of "true" will be sent in the Authorization header.

     digest-response   = 1#( username | realm | nonce | ... | [userhash] )
     userhash          = "userhash" "=" ( "true" | "false" )

1.2.1 Username-Digest

  If the userhash key has the value "true", the client MAY calculate a
  hash of the username in the following way AFTER any other hash
  calculation:

        username = H( H( username ":" realm ) ":" nonce)

1.3 Authentication-Info Header

  The server may change the nonce value, so the client has to
  recalculate the hashed username.

2 Example

2.1 WWW-Authentication Header

  The server responses with a HTTP 401 authentication challenge and
  sends a userhash key with the value "true":

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Digest
           realm = "Example Realm",
           qop = "auth",
           algorithm = "SHA2-512-256",
           nonce = "ce6f0301ca094a6fb25e17c5ea576ac8",
           opaque = "d76e0b4e364548c809251f38100a8be7",
           charset = "UTF-8",
           userhash = "true"

2.2 Authorization Header

  If the client supports hashed usernames, the authorization header
  contains a userhash key with the value "true" and a hashed
  username:

     Authorization: Digest
           username = "73affedb6a2e5ec464eb1c36b61eb2b8",
           realm = "Example Realm",
           nonce = "ce6f0301ca094a6fb25e17c5ea576ac8",
           url = "/example.html",
           nc = "00000001",
           cnonce = "cde966df34a49d5d842a263604159141",
           response = "0ccc423f476e4f7deb8b4c6fbd7a0cc2",
           opaque = "d76e0b4e364548c809251f38100a8be7",
           userhash = "true"

2.3 Authorization Header Without Hashed Username

  If the client does not support hashed usernames, the userhash key is
  missing or has the value "false":

     Authorization: Digest
           username = "Username Example",
           realm = "Example Realm",
           nonce = "ce6f0301ca094a6fb25e17c5ea576ac8",
           url = "/example.html",
           nc = "00000001",
           cnonce = "cde966df34a49d5d842a263604159141",
           response = "0ccc423f476e4f7deb8b4c6fbd7a0cc2",
           opaque = "d76e0b4e364548c809251f38100a8be7",
           userhash = "false"

3 Benefits

  The proposal has several benefits for security and compatibility with
  older HTTP clients.

3.1 Security

  With the hashed username the real username can not be revealed easily
  by an intruder like in a man in the middle attack. A hashed username
  also provides additional protection for the request-digest, where
  the real username and the password will then be unknown.

3.2 Compatibility

  If the client does not understand the userhash key sent by the
  server, the client may try an authorization with a plain username.
  The server can detect the plain username by the missing userhash key
  or the userhash key with the value of "false". In this case the
  server may need to calculate the hash of the username for further
  validation.

---

From: Michael Sweet <[email-masked]>
Date: Sat, 21 Dec 2013 12:17:24 -0500

+1

Reasonable approach and clearly opt-in by both sides.

On Dec 21, 2013, at 10:51 AM, Sophie Bremer <[email-masked]> wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Dec 2013 20:51:08 +0000

Hi

Speaking as an individual, I agree.

>>          opaque = "d76e0b4e364548c809251f38100a8be7",

This challenge has some stuff that current clients don't recognize: there's the userhash key. The question is whether this will cause any breakage. Granted, we already may be causing a problem by adding the charset key and some new values for the algorithm key. I think it would be great if someone wrote a simple server that returns a challenge like the above, so we could test that existing clients can deal with these responses.

Yoav

---

From: Sophie Bremer <[email-masked]>
Date: Sun, 22 Dec 2013 09:31:10 +0100

Hello,

I published my test scripts and noticed only problems with the algorithm key.

http://tests.netzkonform.de/Digest-2013-12-22/MD5
http://tests.netzkonform.de/Digest-2013-12-22/SHA2-256
http://tests.netzkonform.de/Digest-2013-12-22/SHA2-512-256

Best regards,
Sophie

---

From: Yoav Nir <[email-masked]>
Date: Sun, 22 Dec 2013 08:54:39 +0000

Apparently, you're page is in Indonesian :-)

Anyway, that's good to know. And it seems that all the browsers I've tested (Chrome, Firefox, Safari, IE10, wget, and IE for Windows phone) are tolerant.

So given that apparently this *can* be deployed without breaking existing connectivity, and given that some people on this list feel that protecting the user name may be a worthy goal, does anyone still object to adding this to the revised Digest document?

Yoav (with chair hat on)

-----Original Message-----
From: Sophie Bremer [mailto:[email-masked]]
Sent: Sunday, December 22, 2013 10:31 AM
To: Yoav Nir
Cc: Michael Sweet; <[email-masked]>
Subject: Re: [http-auth] New Proposal For Hashed Username

Hello,

Best regards,

Sophie

Email secured by Check Point