BASIC authentication Issues with IE
From: hector (nospam_at_nospam.com)
Date: Fri, 26 Mar 2004 03:46:30 -0500
IE Basic Authentication has always had some kind of quark and it seems the
quarks has either gotten worst or Microsoft is now forcing some behavior
change "issue" on people.
In short, it is so time consuming, with little input directly from the
horse's mouth, to try to understand Microsoft's variant BASIC Authentication
implementation as it is today, how it suppose to work.
Now we got customers who are telling us the passing the username/password on
the URL doesn't work anymore with the latest IE update. I am not sure if
that's true or its related to some "quirky" situation or combinations of
situations with the user's machine setup or even OS related.
So I asking someone if they can summarize or point me to some updated
(current) document explaining what is going on with Windows's concept of
persistent or non-persistent user credentials and the IE behavior.
This is the chronological history as we experienced it:
Originally, the only IE issue we had was......
1) Intermittently, a basic authenticated session is lost when a user
finishes a download. The next URL clicked requires a re-login.
2) Intermittently, a basic authenticated session is lost when a user closes
a secondary popup window. The next URL clicked requires a re-login.
We could never get a handle on this and not all customers experienced it on
their intranet web server installation of our product. I personally use to
see it more than it was reported by customers, so it left me believing it
was something specific to my own OS/IE setup on my machine. I would ask
beta testers "Hey do you see this with IE?" and I would get "No Hector, not
happening here." I researched the problem but never got straight
solution. It looked like it might related to HTML frame operations, but
wasn't sure because I could not get any consistent behavior. It was
3) Within the last year, customers began to report that the BASIC
authentication was persistent.
In other words, I got reports such as:
"Hey, I closed the browser to log off, but the next time
I popped it up, the web server is not asking me to login."
I first, I would say:
"You're nuts! Do you know what that means? That's a fundamental
security flaw and there is no way Microsoft would allow such an
obvious security violation. There has got to be something else going
I told them it was probably related to maybe having "active desktop" and
Microsoft on-going strategy on making everything browser based, so even if
they closed the "browser windows," it was still running in the background,
i.e, Explorer. But checking thing out myself, I could not repeat the
But then I upgraded to one of the IE security patches last year and began to
see this behavior myself!!!! I was totally flabbergasted.
So the first thing I did was apologize to the customers who reported this
and promised to research and check it out. This is now a fundamental
problem for our intranet web server which depends on standard HTTP Basic
Authentication for all browsers.
After researching the problem, I finally saw that it was related to some
background service "inetinfo.exe" and how it caches user credentials and it
was very apparent when you used "Thumbviewing" or Previewer concepts in
I was able to repeat the problem by creating a URL shortcut with notepad
such as: c:\winserver.url with the following lines in it:
Our web support site requires authentication but when you first contact it,
it will redirect you to an non-authenticated login home page. Once you
login, it redirects you to the authenticated home page.
When you use explorer to open the C:\ root folder, and then you highlight
(put your cursor on) the Winserver ICON, Explorer would show on the left
hand side a "small preview" of the HTML page. If you have not
authenticated yet, then Explorer correctly would show the unauthenticated
home page, as expected.
However, if you had logged in and then closed the browser window, the next
time you use explorer to preview the Winserver URL, you would see the
"authenticated home page" as if it automatically authenticated the user
So the customer was correct. Somehow "windows" remember the user
credentials even after you closed the browser.
It was repeatable so I thought it was prudent to call Microsoft and report
this security problem with what seem to be a bug with the "previewing
feature" of Explorer and/or how it related to the cached user credentials.
Well, at first, the Microsoft contact said he was able to repeat it but then
backed off and didn't admit to anything. I guess it was standard Microsoft
policy. I felt that regardless of not coming straight out and saying "Ok,
its a real problem, thanks for reporting it. We'll fix it in the next
patch," Microsoft would not be responsible and not further investigate the
problem and fix it. Microsoft will not ignore this.
In the mean time, I found information that you can set in the registry that
tells INETINFO.EXE to limits its caching of the user's credentials. This
fixed the problem permanently. But I have never saw any reference to this
in subsequent IE or OS updates.
4) Recently I reinstalled Windows 2000 due to a hardware crash, got all the
updates. Everything seem normal.
But now we are about to release a new version of Web Server with new HTML
pages layouts and I see #1 and #2 constantly.
All we did was add a HELP button to our html pages and when you close the
HELP window, the Basic Authentication is lost. The user has to relogin
again! It is 100% repeatable!
What gives? What's going on? I am throwing my hands up. You simply can't
kept up with Microsoft and their constantly "design behavior" changes.
What is the basic rules now with IE's Basic Authentication behavior?
thanks for any input you can provide