RE: BASIC authentication Issues with IE

From: rwg (a-robg_at_online.microsoft.com)
Date: 03/26/04 

Date: Fri, 26 Mar 2004 14:29:22 GMT

| 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/security/bulletin/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
|
|
|
|
|