A combination of expired HTTP password (for instance an expired SecurID token code) and the 302 HTTP status code (Moved Temporarily) breaks the IE authentication mechanism. After the password expires and the user tries to retrieve a page, IE prompts the user for the new password. However, if IE receives a 302 Status Code instead of a 200 after a successful HTTP authentication, it attempts to retrieve the moved page with the OLD (cached and expired) password. When this fails, IE prompts the user for the new password, retrieves this page successfully, but then goes on to retrieve the next page (or page element) with the old password. This behavior repeats ad infinitum, or until the SecurID token is locked because ACE detects a replay or simultaneous authentication attack. This was tested with IE 5.5, but is anecdotally known to break all MS version 5 browsers. Here's what happens: 0) User authenticates and accesses the site normally. User then stops using the application for a period of time and the user's password times out. 1) User goes back to using the site after the timeout period, and at first IE attempts to retrieve a page using her old cached one-time HTTP password (test/0000111111). Because this password is no longer valid, user receives HTTP 401 Unauthorized: Authorization: Basic dGVzdDowMDAwMTExMTEx GET /application.html HTTP/1.1 ... HTTP/1.0 401 Unauthorized 2) User is prompted and puts in her new and valid (SecurID) password (test/0000222222). User receives a 302 Moved Temporarily: Authorization: Basic dGVzdDowMDAwMjIyMjIy GET /page.html HTTP/1.1 ... HTTP/1.1 302 Moved Temporarily Location: /timeout.html 3) BUG: For some reason, IE attempts to retrieve the page that the user is redirected to (/timeout.html) using the OLD HTTP password (test/0000111111). As expected, user gets 401 Unauthorized. Authorization: Basic dGVzdDowMDAwMTExMTEx GET /timeout.html HTTP/1.1 ... 401 Unauthorized 4) Once again, user is prompted and puts in her (next SecurID) HTTP password (test/0000333333). User receives a 304 Use local copy (which is OK since the page has been cached at some point before). Authorization: Basic dGVzdDowMDAwMzMzMzMz GET /timeout.html HTTP/1.1 ... HTTP/1.1 304 Use local copy 5) The /timeout.html page contains a gif file (spacer.gif) that the IE browser attempts to retrieve it (or rather, IE checks to see if it needs to retrieve it or it's already in cache). Once again, IE incorrectly attempts to retrieve this element using the OLD password (test/0000111111) and understandably gets a 401 Unauthorized error: Authorization: Basic dGVzdDowMDAwMTExMTEx GET /spacer.gif HTTP/1.1 ... 401 Unauthorized 6) User is prompted and puts in her (next SecurID) HTTP password (test/0000444444). User receives a 304 Use local copy (which is OK since the gif file has been cached). Authorization: Basic dGVzdDowMDAwNDQ0NDQ0 GET /spacer.gif HTTP/1.1 ... HTTP/1.1 304 Use local copy At this point, the user goes back to the site, but once again, IE tries to retrieve the page using the OLD password (test/0000111111) and gets a 401 Unauthorized error. This continues on and on and on and on for every element of every page. This does not happen in any Netscape browser. I am interested if people have seen this, and if there are any workarounds. This bug has been submitted to Microsoft. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
This archive was generated by hypermail 2b30 : Fri Jun 29 2001 - 15:16:35 PDT