[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 #6 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-02-01 23:54:02 UTC ---
Okay, well, I'm approximately 98% sure that this bug is going to be closed
WONTFIX anyway.  But at the risk of continuing a pointless argument
(http://xkcd.com/386/):

(In reply to comment #5)
> That's what I'm trying to explain.  I guess "better" is subjective, but the
> fewer levels of indirection that exist between what the user agent's secret and
> the actual secret, the more confident you can be that you are dealing with
> someone who has really provided the actual secret.

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.  If
your protocol provides the actual secret to adversaries, like by broadcasting
it in plaintext on every HTTP request, that is a security vulnerability.  You
can't deal with all cases where the adversary learns the password, but you can
avoid exposing it yourself.

> SSL means this isn't a problem.  Unless SSL is broken, in which case we have
> sure got a lot of bigger worries.

The overwhelming majority of websites do not use SSL, nor will they use SSL in
the foreseeable future.  It's all very well for academics to assume everyone
uses SSL, but HTML5 is concerned with the real world, not academics.

> This is exactly my point.  This is a matter of opinion, but I think that what
> you describe above is somewhat irresponsible.  If you have important data that
> should not be revealed to people that don't have valid credentials to your
> application, then it is not sufficient to secure only against the internet. 
> Each tier of the application must also be secured against the others.

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

> Why do you suppose that user credentials and database credentials must be
> distinct?

Because I've never heard of any real-world web application where they're the
same.  At least in MySQL, it would be completely ridiculous -- it wouldn't
scale to the necessary number of users and permissions aren't granular enough
to be useful.  Again, this is about real-world use-cases, not theoretical
worlds where everyone writes software in some idealized modular way.

> If an application user is also a database user (which makes logical
> sense, because in a way your application is merely a front-end for the
> database), then each user can even be assigned the appropriate privileges in
> the database to prevent that user from harming or stealing the data of other
> users.  Now if Joe User does become the victim of social engineering, the
> hacker that stole his credentials will only be able to harm Joe User and not my
> entire userbase.

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

> 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.  You've only talked
about theoretical scenarios, no actual real applications that people are using
that would benefit from this change.  Nobody is going to waste time
implementing HTML features unless it's likely that they'll be *widely* used.

> Now, at the risk of further debate, let me ask: If by some miracle my proposal
> were accepted, and a year from now it were easily possible to use HTTP
> authentication (either basic or digest) and retain your nice-looking login
> forms and logout buttons, would you continue to use session-based
> authentication instead?  If so, why? You would probably be able to eliminate
> sessions entirely from a large portion of your work and have fully RESTful web
> applications.  What is it about cookies that make them better for
> authentication other than the fact that they currently have the features that
> would be addressed by my proposal?

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.

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.

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.

-- 
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 Tuesday, 1 February 2011 23:54:05 UTC