Subject: [http-auth] Username Protection is an excellent goal

From: Jonathan Stoke <[email-masked]>
Date: Sat, 14 Dec 2013 17:10:34 -0700

Protecting the username is just as important as protecting the password.
 At best, username disclosure permits a brute-force attack to be directed
at an identified target.  At worst, username disclosure gives up half of
the information used to protect an identity.

Without reservation I support adding a goal to the charter to protect
usernames.

jonathan stoke

>
>
>
> Today's Topics:
>
>    1. Re: HTTP Digest - Username Protection (Rifaat Shekh-Yusef)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 Dec 2013 13:25:59 -0500
> From: Rifaat Shekh-Yusef <[email-masked]>
> To: "[email-masked]" <[email-masked]>,
>         [email-masked],  Sean Turner <[email-masked]>
> Subject: Re: [http-auth] HTTP Digest - Username Protection
> Message-ID:
>         <CAGL6epL=
> [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Sean, Stephen,
>
> Any thoughts about this?
>
> Regards,
>  Rifaat
>
>
>
>
> On Tue, Dec 10, 2013 at 2:53 PM, Rifaat Shekh-Yusef
> <[email-masked]>wrote:
>
> > Hi,
> >
> > The HTTP Digest Authentication mechanism protects the transport of the
> > user's password, but does not provide any protection to the user's
> username
> > as it is transported in plain text that can be easily intercepted in
> > connections without TLS or with a "Man in the Middle" attacks.
> >
> > Sophie and I have been discussing a way to address this limitation and we
> > would like to add this goal to the charter, but we would like to get the
> > opinion of the ADs and WG and on this.
> >
> > We would appreciate any feedback on this request.
> >
> > Regards,
> >  Rifaat
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/http-auth/attachments/20131213/24f278cd/attachment.html
> >
>
> ------------------------------
>
>

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 Dec 2013 01:38:53 -0600

Protecting the username in the password verifier databases is even
more important: because it greatly increases the workload for off-line
dictionary attack (even if it only adds a few bits, a few bits is a
big deal).  And note that no protocol changes are required here.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Dec 2013 08:16:04 +0000

[with no hats]

I guess this depends. Without TLS, protecting the username is transit is very important. Otherwise you can just monitor the traffic of websites and based on IP address track the users around the world. With TLS present, I guess the password repository becomes the weak point.

On Dec 15, 2013, at 9:38 AM, Nico Williams <[email-masked]> wrote:

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

---

From: Michael Thomas <[email-masked]>
Date: Sun, 15 Dec 2013 06:46:08 -0800

>> big deal).  And note that no protocol changes are required here.

There seems to be a pretty big push for tls everywhere -- a Good Thing. Assuming that
happens, is there a large problem with username protection left to be solved that doesn't
involve saying "use TLS"?

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Dec 2013 15:17:12 +0000

> involve saying "use TLS"?

There's a push for TLS everywhere, but there's also some pushback. I think there's something as close to consensus as we can get that user authentication should be in TLS.

If you go over to the HTTPbis mailing list, you're going to find a long, long discussion of TLS proxies (often called MitM proxy, or decrypting proxies or trusted proxies). Regardless of how that discussion concludes, such proxies are already widely deployed. Also, no matter how "explicit" or "trusted" such a proxy is, I don't want it to see cleartext usernames and passwords. It hinders troubleshooting, because any memory dump is likely to hold information that should not be shown to a vendor.

While I agree that both Basic and Digest should not be used without TLS, there is still value in hiding PII even when it's encrypted by TLS.

Yoav

---

From: Sophie Bremer <[email-masked]>
Date: Sun, 15 Dec 2013 19:44:54 +0100

Hello Yoav,

Well, not in every part of the world you may use TLS.
We have customers in Asia, that are not able to connect via TLS, and at least the user credentials should be protected in this case.
This is for me the main reason, to see hashed usernames in the Digest Authentication.

Best regards,
Sophie

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Dec 2013 09:10:32 +0000

Hi

So let's make this a consensus call.  Currently our charter says this:

  For the digest scheme, the new specification will incorporate "more
  modern" algorithm agility and internationalization support, which
  requires input from internationalization experts.
  draft-ahrens-httpbis-digest-auth-update documents one possible
  approach that the WG could adopt and modify as it sees fit.

The proposal is to change this to read as follows:

  For the digest scheme, the new specification will incorporate "more
  modern" algorithm agility, identity protection, and internationalization 
  support, which requires input from internationalization experts.
  draft-ahrens-httpbis-digest-auth-update documents one possible
  approach that the WG could adopt and modify as it sees fit.

Note that the only change is adding "identity protection".  We've already heard plenty of arguments in favor. Please do not reply if you just want to say more of the same.  

Please do reply if you object to making this change, either because it's (in your opinion) a waste of time, or is an unworthy goal or whatever. So we're mainly looking for objections here.

If it turns out that there is consensus for this, we will go to the ADs and ask to have our charter amended in that way.

Please reply by the end of December.

Yoav & Matt

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Dec 2013 12:09:52 +0200

So let me take the unpopular stand (always more fun).

Some people mentioned identity protection in the context of non-TLS 
protected digest auth. I think this is a waste of time. Not only is the 
actual data available to the attacker, there's been a lot of work on 
fingerprinting using, e.g., browser characteristics 
(https://panopticlick.eff.org/). And then of course there are cookies...

If we're discussing TLS-protected traffic, then:

- Very little protected traffic today uses Digest (or even Basic) auth.
- Adding identity protection to Digest would IMHO be a non-trivial 
change, much larger than I18N, and would constitute a new auth scheme, 
similar to the other experimental schemes being discussed here.
- I appreciate Yoav's concern about SSL proxies, but I think those 
proxies have lots of cues to track clients, even if identities are hidden.
- As a result, protecting the password database (including user names) 
is much more important than protecting the identity on the wire.

To summarize: I think we should not add it to the Digest charter item. 
If there are volunteers to come up with Digest++ as a separate scheme, 
I'd be happy to see it as a separate WG deliverable.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Dec 2013 13:12:43 +0200

Just a few points:

> - Very little protected traffic today uses Digest (or even Basic) auth.

Web traffic, sure. But I think web services do use HTTP-layer 
authentication.

> similar to the other experimental schemes being discussed here.

Rifaat and Sophie appear to have a concrete proposal, which doesn't seem 
overly complicated.

> proxies have lots of cues to track clients, even if identities are 

My concern is not so much that the proxy can collect information, as 
much as that it becomes hard (for a vendor like me) to debug such a 
proxy, as any core dump may contain usernames and password hashes, and 
passwords are likely to be reused. So associating a password (which you 
can get because digest is susceptible to offline dictionary attack) with 
a username is an issue.

> is much more important than protecting the identity on the wire.

We're designing protocols here, not writing software or installing 
security software. Is there anything we can do to help protect the 
password database?

---

From: Harry Halpin <[email-masked]>
Date: Mon, 16 Dec 2013 12:25:17 +0100

On 12/16/2013 11:09 AM, Yaron Sheffer wrote:
> protected digest auth. I think this is a waste of time. Not only is 
> the actual data available to the attacker, there's been a lot of work 
> on fingerprinting using, e.g., browser characteristics 

W3C does :)

> similar to the other experimental schemes being discussed here.

And one of the reasons why HTTPAuth is not used for high-value data. I 
think more folks would use HTTPAuth if it was updated against a number 
of reasonable attack surfaces.

> proxies have lots of cues to track clients, even if identities are 

So does everything else on the Internet. For example, at W3C we are more 
than aware of the power of device finger-printing. Does this mean we 
don't try our best to defend against various threat models and preserve 
user-privacy? No, of course not.
> is much more important than protecting the identity on the wire.

Agreed, but protecting the identity of the user

Again, one of the continual objections to this kind of work is lack of 
browser vendor implementation interest. We're happy to help explore that 
at W3C jointly with IETF.
> I'd be happy to see it as a separate WG deliverable.

HTTP Auth flavors are so badly out of date that it would probably be 
better IMHO to just make one *really* good new version that we can tempt 
people into implementing than a host of alternatives with varied 
security properties. Implementer time is rather limited.

>> Note that the only change is adding "identity protection". We've 
>> already heard plenty of arguments in favor. Please do not reply if 
>> you just want to say more of the same.
>>
>> Please do reply if you object to making this change, either because 
>> it's (in your opinion) a waste of time, or is an unworthy goal or 
>> whatever. So we're mainly looking for objections here.
>>
>> If it turns out that there is consensus for this, we will go to the 
>> ADs and ask to have our charter amended in that way.
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Dec 2013 13:35:52 +0200

Below.

	Yaron

> Web traffic, sure. But I think web services do use HTTP-layer
Agreed. Though I wish they'd used TLS-PSK.

> Rifaat and Sophie appear to have a concrete proposal, which doesn't seem

I'm not sure about that once you start adding crypto-agility. Again, 
this is a fine idea but might be too much as a Digest "tweak".

[snip]

> security software. Is there anything we can do to help protect the
In fact Rifaat's proposal 
(http://www.ietf.org/mail-archive/web/http-auth/current/msg01623.html) 
does that. And obviously the password database is strongly tied to the 
protocol you're using. See for example the discussion on the TLS ML re: 
"balanced" vs. "augmented" PAKE.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 16 Dec 2013 11:55:00 -0500

FWIW, I agree that a "protected" (hash, whatever) username version of Digest deserves its own scheme - not only will it avoid expected interoperability issues with existing Digest implementations, it will allow the new scheme to dump legacy baggage like MD5.

That said, I don't agree that this would be a waste of time - certainly it doesn't offer much in the way of passive monitoring protection, but it would help protect against active attacks against individual accounts since the username is not exposed in the clear and typically isn't an email address but a different identifier chosen by the user and/over administrator...

On Dec 16, 2013, at 5:09 AM, Yaron Sheffer <[email-masked]> wrote:

> Some people mentioned identity protection in the context of non-TLS protected digest auth. I think this is a waste of time. Not only is the actual data available to the attacker, there's been a lot of work on fingerprinting using, e.g., browser characteristics (https://panopticlick.eff.org/). And then of course there are cookies...
> 
> - Adding identity protection to Digest would IMHO be a non-trivial change, much larger than I18N, and would constitute a new auth scheme, similar to the other experimental schemes being discussed here.
> - I appreciate Yoav's concern about SSL proxies, but I think those proxies have lots of cues to track clients, even if identities are hidden.
> - As a result, protecting the password database (including user names) is much more important than protecting the identity on the wire.
> 
> To summarize: I think we should not add it to the Digest charter item. If there are volunteers to come up with Digest++ as a separate scheme, I'd be happy to see it as a separate WG deliverable.
> 
> Thanks,
> 	Yaron
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Phil Hunt <[email-masked]>
Date: Mon, 16 Dec 2013 10:43:18 -0800

There are good reasons to support the non-TLS case - and not because unprotected sites should be supported. Even with TLS enabled services it turns out real-world systems often have load-balancers and gateways such that TLS terminates at the balancer and is not end-to-end. Of course this type of architecture may change with certain agencies tapping internal network fibre - but it is in wide use.  I'm not saying this is a good or bad thing, only that it is a problem.

In the OAuth-WG we are discussing a MAC token to provide session auth.  We discussed using TLS mutual auth approaches but discovered this issue.  So TLS authentication is not end-to-end authn and the session/user authn should be end-to-end.  

Finally it seems like good design to assume end-points could be compromised at some point. So the mechanism should take into account theft of tokens/keys. Case in point, take a look at the buffer.com story: 
http://www.thread-safe.com/2013/11/oauth-protects-users-in-compromise-of.html
http://blog.programmableweb.com/2013/11/04/why-the-attack-on-buffer-was-a-serious-wake-up-call-for-the-web/

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-12-16, at 3:12 AM, Yoav Nir <[email-masked]> wrote:

> Web traffic, sure. But I think web services do use HTTP-layer authentication.
> 
> Rifaat and Sophie appear to have a concrete proposal, which doesn't seem overly complicated.
> 
> My concern is not so much that the proxy can collect information, as much as that it becomes hard (for a vendor like me) to debug such a proxy, as any core dump may contain usernames and password hashes, and passwords are likely to be reused. So associating a password (which you can get because digest is susceptible to offline dictionary attack) with a username is an issue.
> 
> We're designing protocols here, not writing software or installing security software. Is there anything we can do to help protect the password database?
>