Troubleshooting Authentication with Fiddler

Over the last few weeks, I’ve been exchanging mail with a webmaster (Vladimir) in Russia who reported that his customers were having problems using IE8 on Windows 7 to log into his website. His site uses HTTP Basic Authentication, so users are prompted to enter their credentials using the following dialog:

I asked the webmaster to submit some HTTP Traffic Logs collected by the lightweight network traffic capture tool known as FiddlerCap. He obliged, and I used Fiddler to take a look at the captured .SAZ traffic log.

Fiddler includes an “Auth” Inspector that allows you to easily look at the HTTP Authentication credentials sent for a given request. I opened the .SAZ file captured with FiddlerCap. In the failing case, he had entered the username test and the password ABCDEFG. The Auth inspector, however, showed that the password wasn’t being sent:

As you can see, the base64-obfuscated string is quite short, and the decoded username:password string contains only the username and the colon, but no password at all.

Now, I didn’t have ready access to the customer’s test page, but wanted to try to reproduce the problem myself. I don't have a server that required Basic auth handy, but Fiddler makes it simple to simulate scenarios such as this. I simply used the AutoResponder tab to create a rule that responds to any request for a URL that contains the string “AUTH” with a HTTP/401 response that demands Basic authentication:

Fiddler includes about a dozen sample responses like the 401_AuthBasic.dat, and you can easily use Fiddler to capture other responses, or even create your own using any text editor.

With this AutoResponse rule in place, I can request any invented URL containing the word "auth" and get an authentication prompt in response. I tried https://www.example.com/auth and received the expected authentication prompt. I typed in some credentials, submitted them, and took a look in the response inspector. I found that the credentials were submitted perfectly:

As you can see, the base64-obfuscated string is longer, and the decoded username:password string contains both the username and password, split by the colon. So, I wasn’t able to reproduce the behavior reported by the web developer, despite trying a number of different reproduction cases. However, he was fortunately quite persistent and did some additional research, determining that the problem only existed when the password was pasted from the clipboard.

This was an interesting finding, and narrowed down the problem substantially.

First, a bit of background. In Windows 7, WinINET was updated to call the CredUIPromptForWindowsCredentials function to collect HTTP Authentication credentials. The function shows a new CredUI dialog that offers an improved UI over the legacy password prompt, and its use is recommended for use on Windows Vista and later (although IE8 only uses it when running on Windows 7).

Now, experienced developers in the audience know that any time anything is changed, there’s always a chance of regression, so, coupled with the fact that the problem was narrowed down to just the password-paste case, we had some leads. At first, I thought it likely that the problem was related to the Russian version of Windows 7, because I didn’t have any problems with pasting in the password with CTRL+V on the English OS. So, I asked Vladimir to collect screenshots of all of the different formats on his clipboard. This is easily done with a free little utility called ClipSpy. I suspected that perhaps there was a codepage-related problem where the password characters were perhaps being mangled because the system codepage was Cyrillic. However, the output of the ClipSpy tool didn’t reveal anything interesting; Vladimir's clipboard's bytes looked just like my clipboard's.

At this point, I was stumped. I wasn’t able to reproduce this problem in-house, and had tried on many different Windows 7 computers, using a variety of different sites and passwords. Then, Vladimir saved the day by forwarding along a posting on a message board where a customer complained of exactly the same problem. The response from “auggy” indicated that the user should try using CTRL+V to paste rather than using the context menu.

I had always been pasting with CTRL+V and had never tried using the context menu; Vladimir's repro steps hadn't mentioned the context menu, and it didn't even occur to me that it could make a difference-- typically the context menu and CTRL+V behave identically.

After playing with the context menu’s Paste option, I was very quickly able to reproduce the problem. It turns out that there is a tiny bug in the CredUI dialog on Windows 7. If you use the CredUI dialog's context menu to paste into the username or password dialog box without pressing any key in the box (e.g. tab, CTRL+V, CTRL+A, etc) then, while the text appears to be updated, the internal data structures are not updated. The internal username or password data remains unchanged from its original value until a key is pressed. In the failing cases, the boxes started out empty, so when the user used the context menu to paste into the password box, the password data was never updated away from the blank value.

I’ve passed this bug along to the CredUI team for further investigation. May 2011 Update: a fix for this issue is available for download at https://support.microsoft.com/kb/2547752. I’d like to thank Vladimir for his patience as we hunted down the core problem and for his willingness to provide network captures and other information.

Hopefully, this post has shown you a few ways that you can use Fiddler to find the root cause of problems (and eliminate confounding variables from the repro) and reiterates the value of providing painstaking detail when sharing bug repro steps.

-Eric

PS: My "Debugging with Fiddler" talk at the Microsoft PDC is now available for online viewing.