|
Home > Archive > IIS Server Security > March 2004 > BASIC authentication Issues with IE
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BASIC authentication Issues with IE
|
|
| hector 2004-03-26, 11:49 am |
| 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
intermittent.
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
on."
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
problem.
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
Explorer.
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:
[DEFAULT]
BASEURL=http://www.winserver.com
[InternetShortcut]
URL=http://www.winserver.com
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
again.
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
Hector
| |
|
| | 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.
I think this is the security patch that blocks this unsecured function:
http://www.microsoft.com/technet/se...n/MS04-004.mspx
| 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.
Basic authentication is an industry standard, and if you don't use it on SSL channel, then it's not secure.
| "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."
...
| "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
| on."
IE will automatically send passwords to browser in the "Trusted Zone" and can be configured to automatically send or not send passwords in any of the
zones. In IE, menu:Tools -> Internet Options -> tab:Security -> button: Custom Level -> Scroll to the bottom of the Security Settings and look at "User
Authentication" choices. This is, of course, a browser issue, not an IIS issue.
-rwg
This is what I think, not necessarily what is accurate!
--------------------
| From: "hector" <nospam@nospam.com>
| Subject: BASIC authentication Issues with IE
| Date: Fri, 26 Mar 2004 03:46:30 -0500
| Lines: 135
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="iso-8859-1"
| Content-Transfer-Encoding: 7bit
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uYt0k6wEEHA.2088@TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.inetserver.iis.security
| NNTP-Posting-Host: adsl-218-24-8.mia.bellsouth.net 68.218.24.8
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.inetserver.iis.security:10623
| X-Tomcat-NG: microsoft.public.inetserver.iis.security
|
| 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
| intermittent.
|
| 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
| on."
|
| 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
| problem.
|
| 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
| Explorer.
|
| 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:
|
| [DEFAULT]
| BASEURL=http://www.winserver.com
| [InternetShortcut]
| URL=http://www.winserver.com
|
| 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
| again.
|
| 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
|
| Hector
|
|
|
|
|
| |
| Tom Kaminski [MVP] 2004-03-26, 11:54 am |
| ""rwg"" <a-robg@online.microsoft.com> wrote in message
news:aEEG86zEEHA.608@cpmsftngxa06.phx.gbl...
> IE will automatically send passwords to browser in the "Trusted Zone" and
can be configured to automatically send or not send passwords in any of the
> zones. In IE, menu:Tools -> Internet Options -> tab:Security -> button:
Custom Level -> Scroll to the bottom of the Security Settings and look at
"User
> Authentication" choices. This is, of course, a browser issue, not an IIS
issue.
For clarification that only applies to Windows Integrated authentication (or
NTLM on IIS) and not Basic authentication.
--
Tom Kaminski IIS MVP
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://mvp.support.microsoft.com/
http://www.microsoft.com/windowsser...ty/centers/iis/
|
|
|
|
|