[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 #4 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-02-01 00:56:56 UTC ---
(In reply to comment #3)
> Let me try to explain further.  When cookies are used for authentication,
> essentially a "surrogate secret" -- namely, the Session ID or whichever cookie
> mechanism you are using -- is created, which is then used to authenticate the
> user.  That surrogate secret is then transmitted to the server on each request.

Instead of transmitting the secret itself on every request.  Why is that any
better?

>  The primary reason this isn't as secure as HTTP authentication is that the
> surrogate secret is being stored in other places besides the user agent and the
> user's brain.  The session ID, for example, is stored somewhere in a data store
> or in a temp directory somewhere, and it could conceivably be hijacked because
> of that.  When the secret itself is used (as in the case of HTTP
> authentication), the secret does not need to be stored anywhere except in the
> user's brain and the user agent's memory.

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.

> On each request you know for a fact
> that they have provided their credentials - with a cookie, the user could
> merely have stolen the session ID.

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

> There are ways to make the cookie-based
> authentication more secure than I have described, but it can never be as secure
> as when the user agent directly provides the credentials on each request.

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.

> I'm glad you asked.  Consider a typical web application in which the server
> connects to some database, performs some logic, and allows the end user to
> interact with that data and logic via HTTP.  99% of all web applications
> written in this way will have, in some config file or maybe even hard-coded
> (ugh), a connection string which specifies the credentials to connect to the
> database.  This is not very secure, because if that code or config file is
> stolen, those credentials could be used by a hacker to access the database.

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.)

> In the case of HTTP authentication, the application can be written in a way
> that it is unnecessary to store any database credentials.  If the
> authentication is delegated to the database itself, then the application can
> simply prompt for credentials over HTTP, and forward those credentials when
> connecting to the database.  In that way, all database credentials are stored
> nowhere except the users' brains.

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

> I'm not suggesting that the standard be changed simply to accommodate an edge
> case like this.  I *am* suggesting that HTTP authentication is a useful but
> incomplete part of web development and rather than being left to die, it should
> receive the small bit of attention it needs to be a complete authentication
> solution for web applications.  What I've described in the above paragraph
> shouldn't be an edge case - it should be common practice, in my opinion.

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.

-- 
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 00:56:58 UTC