Subject: HTTP Basic Authentication

From: Jim Flath <[email-masked]>
Date: Fri, 27 Feb 2004 08:35:32 -0500 (EST)

I am building a system that is constructed using servlets and JSPs, I also utilize Session’s and client cookies.  

I am curious if I am truly implementing Basic Authentication or a mutated version of that.  Here is the flow:

First request:

Client makes initial request to a secure resource.

Server finds no session data to indicate previous authentication.

Server checks header values for credentials, no credentials found, replies with a 401 status code.

Client receives 401 and prompts for credentials, receives user input and sends the authentication header data.

Server interrogates the header data and authenticates the user to the realm

Server saves user data and flags in the session to indicate that they have successfully authenticated to the realm.

Server serves up the resource.

Subsequent request with a valid session:

Client request to same or different secure resource within the same realm.

Session is still valid and server finds authentication flags in the session, does NOT resend 401 status code.

Server serves up the resource.

Subsequent request with invalid session:

Subsequent request to same or different secure resource within the same realm.

Session has been invalidated, no session data found.

Server checks header values for credentials, no credentials found, replies with a 401 status code.

Client receives 401 and sends cached credentials in the authentication header.

Server interrogates the header data and authenticates the user to the realm

Server saves user data and flags in the session to indicate that they have successfully authenticated to the realm.

Server serves up the resource.

Does the server need to reply with a 401 for each and every request to a secure resource within the same realm to say I am using Basic Authentication?  That type of model would seem to be inefficient. I understand that HTTP is a stateless transaction, but with the addition of sessions and cookies the entire transaction becomes stateful to a point.

FYI, the entire transaction is accomplished using HTTPS/SSL.

---------------------------------
Do you Yahoo!?
Get better spam protection with Yahoo! Mail

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Fri, 27 Feb 2004 16:23:52 +0100

Jim,
 
I'm using IIS6 w IE6 and here the logs shows up the following situation:
Every request to a page that requests authentication will have the 401 200
sequence.
The exception counts for pictures that are part of the HTML page, where IE
instantly authenticates.
 
The use of cookies can indeed save some round-trips to the server. Because
of the use of HTTPS this would be safe enough, though authentication would
be a lot safer. Adverseries might guess the session identifier. Usually this
risk is quite small, though...
 
The inefficiency was done because of security reasons, I assume. If you
authenticate, you send you password out into the open, which is not quite
safe.
 
Note that in the cookies the session identifier is stored and is used to
match the session on the server.
 
- Joris

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jim Flath
Sent: Friday, 27 February 2004 14:36
To: [email-masked]
Subject: HTTP Basic Authentication

I am building a system that is constructed using servlets and JSPs, I also
utilize Sessions and client cookies.  

I am curious if I am truly implementing Basic Authentication or a mutated
version of that.  Here is the flow:

First request:

Server checks header values for credentials, no credentials found, replies
with a 401 status code.

Client receives 401 and prompts for credentials, receives user input and
sends the authentication header data.

Server saves user data and flags in the session to indicate that they have
successfully authenticated to the realm.

Session is still valid and server finds authentication flags in the session,
does NOT resend 401 status code.

Subsequent request to same or different secure resource within the same
realm.

Server checks header values for credentials, no credentials found, replies
with a 401 status code.

Client receives 401 and sends cached credentials in the authentication
header.

Server saves user data and flags in the session to indicate that they have
successfully authenticated to the realm.

Does the server need to reply with a 401 for each and every request to a
secure resource within the same realm to say I am using Basic
Authentication?  That type of model would seem to be inefficient. I
understand that HTTP is a stateless transaction, but with the addition of
sessions and cookies the entire transaction becomes stateful to a point.

  _____  

Do you Yahoo!?
Get better spam protection with Yahoo!
<http://us.rd.yahoo.com/mailtag_us/*http://antispam.yahoo.com/tools> Mail

---

From: David Morris <[email-masked]>
Date: Fri, 27 Feb 2004 15:17:36 -0800 (PST)

Jim,

Basic authentication is pretty obnoxious. Running under HTTPS removes the
fundamental security concern, exposure of open text credentials, but it is
a stateless protocol. Each client request must carry the credentials which
must be validated by the server.

If my memory hasn't failed, a client is permitted to anticipate that a new
URL is part of a particular realm and offer the credentials. Certainly,
once the specific URL has had user entered credentials, the clients
send the same credentials on the next request. I have observed in the past
that some clients may send the same credentials for other URLs which
reference the same 'directory' or even child directories.

The server must sent the 401 when it doesn't believe the client is
correctly authenticated, either because there were no credentials or the
credentials are wrong. It is a slippery slope to expect a user to be
prompted if 401 is sent in response to correct credentials. There is
no protocol mechanism for requesting a client purge credentials.

The only influence the server has over the user authentication dialog is
the 'realm name' so usability is poor at best. I haven't seen a moderate
to high volume production site in years which uses basic or other client
supported authentication. That of course isn't an exhaustive survey. I
find basic authentication most useful in situations where the web security
requirements are equivalent to physical security satisified by an
unguarded locked fence. Perhaps a beta release of a new version or a
a design review where you want to avoid access by casual browsers and
robots.

Application controlled authentication provides the most robust user
experience and the most server flexibility. In simple terms, include a
login page which authenticates the user and then uses a cookie or URL
decoration to track the user session. Enforcement can be achieved with
application page logic, app server support, etc. Beyond the scope of this
list to discuss the alternatives.

Dave Morris