When do browsers push identity within realms?

[lastcraft]

Hi.

This is an outside chance and if I have to explain the question then it is likely that, like me, you don't know the answer, but...

When a browser visits a page protected by authentication, a challenge (401) header is issued with the name of the security realm you are about to enter. After the browser pops up a dialog asking for username/password, the page is requested again with the encoded identification. All this is documented in the HTTP 1.0 protocol. So far, so good.

Now, to save you answering that dialog for every protected page, the browser continues to send that authentication to future requests within what it thinks is the likely realm. It is this behaviour I am trying to determine. I am basically trying to simulate typical browser as much as possible, but haven't manged to find any information on it's choices. Does it continue to authenticate for the directory tree rooted at the first challenge? Does it always authenticate until it fails a later challenge? Is the first realm then discarded? Even if it is in the history list?

I am probably going to have to experiment either way, but if anyone has any knowledge of how the browser decides when to send the identity, and when not to, it would really save me some time.

Anyone have even a scrap of information...?

yours, Marcus

[tedster]

I'm far from an expert in HTTP authentication -- but based on some recent reading I've done, here's a little bit that I'm pretty sure of.

Under basic authentication, the AuthName field protects all the subdirectories down the tree and the browser will send authentication data as long as the match is IDENTICAL.

If there is even a small shift in the apparent server domain name -- say from http://example.com/private/ to http://www.example.com/private/ -- then the browser will NOT automatically send the authentication data, thus protecting the user identity from potential theft. Instead the browser will put the user through another username/password cycle.

Fuzziness comes into the scheme with timeout after idleness. I don't know if most browsers assume a timeout interval and then automatically stop sending the auth data, or if they keep sending the data until the server challenges -- putting the whole burden of a timeout/idleness decision on the server.

I suspect, but do not know for sure, that the second scenario is the case, since modern browsers give the user the option to store passwords and usernames. However, it is possible that the server sends timeout/idleness data that the modern browser uses to determine what data to include in its requests.

[py9jmas]

Watching requests going through my Squid proxy, Mozilla seems to do this:

1. You request page
2. Page returns 401 authentication required with realm name
3. Mozilla prompts for username/password
4. Mozilla retries request with username/password
5. Mozilla caches username/password.
6. Mozilla continues requesting pages without authentication
7. If it gets anymore 401s with same realm (and I assume within the same domain etc), it automatically retries with the cached username/password. If it works, go to step 6 else go back to step 3.

In other words, if you are browsing a password protected site, Mozilla ends up requesting everything twice - once without authentication and then again with.

HTH,

Jon.

[hyperbole]

tedster: I agree with your description of when the browser sends the authentication data. I beleive the browser continues to send the data until you exit the program. This means that the timeout issue has to be handled by the server.

If you have several windows open and have logged into a secure site with one, the browser will contilue to send your authtentication data to the site even if you close the window you logged in from. It will continue to do this until you close all instance of the browser.

[tedster]

Mozilla ends up requesting everything twice - once without authentication and then again with.

Thanks for that info. It's a surprising use of bandwidth and it slightly slows browsing experience - but it's very secure.

So my assumption was definitely not true for Mozilla. Nothing like the real world to challenge book learning.

[encyclo]

but it's very secure

Or not... as all passwords are sent as clear text when using basic authentication, so you wouldn't use it for your online banking, for example. Any packet sniffer would do to get access - and it often leaves the user ID / password in the access_log file too.

If you want proper authentication, you'll need to look to a scripted one with passwords sent encrypted or as a hash and compared to a database - all over an https connection, naturally.

[lastcraft]

Hi.

Thanks a lot guys, this info is really useful. I am going to do some experiments anyway, but it is definitely odd that Mozilla completely ignores the option of maintaining identity. Especially as this is explicitely allowed in the specifications (especially Digest Authentication). Netscape 6 (Mozilla 0.8ish if I remember) had some known issues with authentication in general, but I am surprised to see it continue.

The original standards committee clearly had the idea of a file tree being the realm. One header that didn't make it into the spec. was a template describing the extent of the realm...

WWW-Authenticate: Basic realm="MyWorld"
WWW-Protection-Template: /dir1/dir2/*

The browser's on the other hand seem to choose pretty much random approaches :(.

From what I have heard of IE it just throws out the last identity all the time it stays within a host (haven't tested this yet). There is a slight security advantage in Mozilla's approach - if the browser switches realm it could otherwise present the password of one realm to another. If the second realm is "hostile" it could harvest passwords. OK, not very likely given that they are on the same host, but...

Meanwhile I am still investigating. As I am writing a testing tool I've got to poke around in excruciating detail.

yours, Marcus

[rogerdp]

Mozilla's behavior doesn't use much extra bandwidth. Sure, it requests the page twice, but one of those times it's not going to get the page data, just a couple header lines.

[dcrombie]

We use PHP+SQL for authentication on a number of sites. That means we can authenticate for selected pages in a directory. The browser automatically re-sends the username and password when requesting both authenticated and non-authenticated pages - but only in the same directory or below.

w.r.t expiring the session, the only way I know is to quit the browser or re-issue a 401 header. Not sure how long the server holds onto the connection but there must be a setting somewhere. It would be nice to initiate a logout on the server-side instead of playing about with cookies and/or database values...

Question: Does IE(Win) only support one realm per domain? Or does it not recognise the realm at all?