W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[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,

From: <bugzilla@jessica.w3.org>
Date: Tue, 01 Feb 2011 01:38:19 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Pk5CF-0006lJ-El@jessica.w3.org>

--- Comment #5 from Jeremy <jeremy@blazonco.com> 2011-02-01 01:38:17 UTC ---
(In reply to comment #4)
> Instead of transmitting the secret itself on every request.  Why is that any
> better?

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.  If the user agent's secret
is the actual secret, then you have minimized the indirection.  To rephrase: if
the user agent has sent the correct credentials, there is NO WAY that the user
has not provided those credentials.  If the user agent sends a session ID for a
session in which someone has previously provided the correct credentials, then
there IS a way that the user (of the current request) didn't provide those
credentials.  That's what I mean by 100% certain.

> It, or a hash of it, must be stored on the server so that the user can be
> authenticated.  You could store only a hash, but you could also store only a
> hash of the cookie if you like.  The only difference I see is that a cookie can
> be invalidated without changing the underlying secret, so using a long-lived
> cookie means a MITM won't be able to recover the actual password unless they
> happen to be present on the rare occasions when it's sent.  A MITM could
> recover the password on every request if it's sent on every request.

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

> If you send the secret itself, the user could have merely stolen the secret.

Sure, but we can't really consider it our responsibility to prevent the user
from sharing their credentials.  But we can do everything in our power to make
sure that someone else isn't able to access the application as Joe User without
his involvement.

> I really can't see any attack against cookies that can't be carried out against
> the system you describe by an attacker with the same capabilities.

> If we're talking about a typical web application as you say, anyone with access
> to the filesystem of the application server can almost certainly access the
> database server anyway, one way or another.  Web applications are typically
> only secured against attackers outside the local network.  (Of course, there
> are surely some web apps that are atypical in this respect.)

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.

> In what typical (your word) web application would you log into the *database*
> with the *user's* credentials?

Why do you suppose that user credentials and database credentials must be
distinct?  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.  And maybe Joe will learn something about trusting e-mails
from the Official European Lottery.

> In my opinion, if an attacker gains access to your application servers, they're
> generally going to be able to do enough evil things that trying to prevent them
> from also accessing your database is fairly pointless.

Again, this is a matter of opinion, and we are now decidedly off-topic in
discussing security best practices rather than the HTML5 specification.  But if
a hacker somehow gains read access to my code or configuration (which is not
outside the realm of possibility), I don't think he should be able to do evil
things or log into my database.  If the hacker gets write access to my code,
then yes, I am pretty well hosed.  But it's the developer's responsibility to
close as many of these doors as possible, and connection strings are one such
door (and sessions stored on disk are another).

Since we're getting off-topic, let me just summarize the purpose of my
1. HTTP authentication is part of the HTTP standard and is fully RESTful, which
session-based authentication is not.
2. I assert that HTTP authentication is useful and engenders good security
practices, though not everyone agrees with this assertion.
3. HTTP authentication is missing a few key features which could be addressed
in the HTML5 standard, which would make it nearly perfect.  This could be
accomplished without changing the existing HTTP authentication spec.

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?


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 01:38:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:40 UTC