[Bug 11912] HTML5 provides an opportunity to fix a long-running problem with HTTP Authentication. HTTP Authentication is important, because it is the only way to execute a request with 100% certainty that the user has provided an authentication secret. Furthermore,

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912

--- Comment #7 from Jeremy <jeremy@blazonco.com> 2011-02-02 00:26:22 UTC ---
(In reply to comment #6)
> Okay, well, I'm approximately 98% sure that this bug is going to be closed
> WONTFIX anyway.  

Agreed.  I still think it's important to make the case, even though it has no
chance of being heard.

> But at the risk of continuing a pointless argument

I disagree that it's pointless, and I see it as useful debate rather than
pointless argument.  But I'll concede after this that I've no chance of getting
HTTP auth fixed, because most people think like you do.

> 
> 
> Your threat model is wrong.  Your goal is not to deal with a party that
> provided the actual secret -- your goal is to deal with the genuine user.  

Yes, and getting the actual secret is the most I can do to assure I'm dealing
with the genuine user.  At least I know they have the secret.

> If your protocol provides the actual secret to adversaries, like by broadcasting
> it in plaintext on every HTTP request, 

It doesn't.  I use SSL.

> 
> The overwhelming majority of websites do not use SSL, nor will they use SSL in
> the foreseeable future.

Agree to disagree.  Depends on the application.  I don't expect CNN.com to use
SSL, but I sure expect my bank to use it.  Some websites have important,
private information, and they are no less valid than your website.

> 
> However, this is not how almost anyone writes applications in real life. 
> Again, HTML5 is about real-world use-cases, not theory.
>

But my bank is in the real world.  My stockbroker is in the real world.  And I
really hope they don't share that attitude.  I would rather hope they are as
fanatical about protecting data as I am.  And it pains me to think that sitting
in one of their config files somewhere are the keys for stealing all of my
private financial data.

> At least in MySQL, it would be completely ridiculous

No comment.

> 
> This is normally accomplished by permissions checks within the application, not
> the database.
> 

Again, I respect you as a programmer, but don't assume your apps are "normal"
for other sectors.  MediaWiki and similar apps don't necessarily have to
fanatically protect data.  But other applications do.  PCI compliant ones, for
example.

> > 2. I assert that HTTP authentication is useful and engenders good security
> > practices, though not everyone agrees with this assertion.
> 
> Because you haven't provided any real-world use-cases.

I feel like I have.  Maybe you don't agree that my use cases are real-world,
but to my users they are.

> 
> Since I live in the real world, *I write applications* (e.g., MediaWiki) that are
> mostly going to be used over HTTP, not HTTPS.  Sending the password on every
> request is therefore less secure than sending it only occasionally for login.
> 

Emphasis mine.  I think this is the origin of our disagreement.  You write
applications - good ones, at that - which are meant to be widely (in the case
of MediaWiki, *very widely*) deployed by other people who don't necessarily
need, want, or understand how to protect information.  You write those apps to
take advantage of easily available dependencies (i.e. MySQL).  You write those
apps assuming your users probably won't deploy SSL, which they won't.  And
that's exactly what you should do, *in that situation*.  

Not everyone's situation is like that.  Other people live in the real world,
and not all of them write the same apps as you.  I would argue that a lot of
important websites DO need to use SSL and DO need to take fanatical measures to
protect their data.  Fixing HTTP auth once and for all would provide a useful
tool to that end. 

> Also, with cookies, the browser isn't forced to store the password for the user
> to remain logged in, only the cookie.  Thus it's more secure if the user's
> computer is compromised, since it reduces the chance that the password is
> stored on the computer for an attacker to steal.

Two flaws here: 

1. I have never seen an attack which steals credentials out of a user agent's
memory, and if one exists, then it's not my responsibility to combat that. 
It's the author of the user agent who must be on the lookout for such
vulnerabilities.  If you meant that they would steal it out of the user's saved
passwords, then your users' saved passwords are no less vulnerable to that
attack.

2. If the attacker can steal credentials out of the UA's memory, they can just
as easily steal a session cookie, or a 'log me in automatically' cookie.  And
there are many more vectors for stealing a session cookie than the hypothetical
one you described for stealing HTTP credentials.

> 
> If I were writing a quick and simple application, I'd prefer basic HTTP auth if
> it were nice to use, because it's simpler -- although less secure.

Again - when used properly, it is at least as secure, if not more so.  That's
my story and I'm sticking to it!

I'll try to stop debating now.  Again, I know I have very little chance of
being heard.  I can only hope that one of the folks behind RFC 2617 will see
this big argument and think to themselves, "Yeah, HTTP auth *was* a good idea
and we *should* try to perfect it."  Otherwise, I concede your point that I'm
pretty much talking to myself.  I just thought it was important to try.

If you want the last word, go ahead and reply once more - I'll try *really
hard* not to say anything further :)

Jeremy

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 2 February 2011 00:26:25 UTC