[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

Jeremy <jeremy@blazonco.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremy@blazonco.com

--- Comment #3 from Jeremy <jeremy@blazonco.com> 2011-01-31 22:47:18 UTC ---
(In reply to comment #1)
> How is it more certain than with cookies?
> How is the same not true of cookies?
> 

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


> How so?
> How is it that you can avoid storing some form of credentials on the server?
> 

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.

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.

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.

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 Monday, 31 January 2011 22:47:21 UTC