Why Won’t IE Remember My Login Info?

Over on the Microsoft Answers forum, some folks have reported that Internet Explorer doesn’t remember their login details. This is a tricky problem to troubleshoot because there are a number of different problems which get lumped together under this description, and there are a number of different causes for each problem.

Let’s break down the commonly reported problems into two cases:

  1. IE’s Web Forms Password Manager doesn’t work.
  2. Clicking “Remember me” on websites doesn’t work.

The following two sections will discuss each problem and possible causes and solutions.

Troubleshooting IE’s Forms Password Manager

Internet Explorer actually has two password managers: the WinINET-provided password manager that remembers HTTP-based authentication credentials entered in the authentication popup window:


...and a browser-specific password manager that remembers passwords typed into HTML forms. For the purposes of this post, we’re only going to be talking about the web forms password manager.

The Forms-Based Password Manager prompts you to save your password when it recognizes that you’ve filled in a login form. The prompt looks like this:

Autocomplete password prompt

...in IE6,7, and 8. In IE9+, it is replaced by a notification bar at the bottom of the screen that offers the same options:

If you do not see this prompt after submitting a HTML form with a password, there are several

Possible Problems:

  1. You have disabled AutoComplete in your browser by checking the “Don’t offer to remember any more passwords” box.
  2. The page has explicitly disabled AutoComplete by using the AUTOCOMPLETE=OFF attribute.
  3. The HTTPS-delivered page implicitly disabled AutoComplete by returning a HTTP directive forbidding caching. See below
  4. Internet Explorer didn’t recognize that the page had a login form.
  5. The login form was submitted using JavaScript.
  6. You previously said "No" when prompted to save your password for this username on this page.
  7. The Administrator disabled AutoComplete in your browser using Group Policy.
  8. The login form was created by JavaScript using the createElement API.
  9. You didn't type any letters in the Username box (using drag/drop or copy/paste instead)

2013 Update: IE11 Shrinks this list significantly. See below.

You can resolve problem #1 in IE by clicking Tools > Internet Options > Content > Autocomplete > Settings and checking the User names and passwords on forms and Ask me before saving passwords checkboxes.

Issues #2 to #5 are under the control of the website, although most users won't know that (I’ve mentioned this before). There is no way for the user to resolve these problems short of asking the website to update their page.

CORRECTION: Issue #3 is only a problem for AutoComplete of non-login forms. Here's a test page showing that AutoComplete of username and password in login forms works properly even on no-cache HTTPS pages. 2013 Update: IE11 allows even non-logon-form Autocomplete on pages that use Cache-control: no-store.

Case #4 is an interesting one. One possibility is that IE doesn't "see" the login form at all, for instance, because it was written using Adobe Flash, Silverlight, Java, etc). Another possibility is that IE doesn't "recognize" the form as a login form, because it contains more inputs than expected. For instance, Facebook uses a fancy login form that shows the cue text "Password" in a INPUT TYPE=TEXT control (named "Password_Placeholder") until the user puts their cursor in the box. When they do, Facebook uses CSS to hide the password_placeholder box and replaces it with a INPUT TYPE=PASSWORD box into which the user types their password. Unfortunately, while it's hidden by CSS, the placeholder is still a part of the form, and hence it's submitted with the form. Because of this extraneous INPUT TYPE=TEXT control, IE assumes that this isn't a login form and does not offer to save the password. (Using Fiddler, I modified the Facebook homepage to change the placeholder control to INPUT TYPE=HIDDEN and confirmed that this fixed the problem). Update: Facebook fixed this problem in October 2009.

Case #5 is another interesting one. If you submit a form using the JavaScript submit() method, AutoComplete will not offer to save the password. I've built a simple test page which demonstrates this. If you use the standard INPUT TYPE=SUBMIT button, you'll be prompted to save your password. If you use the button which calls the .submit() method, no prompt is shown. To workaround this issue, web developers can call the AutoCompleteSaveForm method.

Case #6 is a tough one. If you previously elected not to save your password for this username for this page , then that “Don’t Store” preference is retained and you will not be prompted to save the password for this username in the future either. There's no "good" workaround for this. Update: There is now a better workaround; see https://blogs.msdn.com/b/ieinternals/archive/2010/04/09/restoring-the-internet-explorer-password-autocomplete-prompt.aspx

You can delete ALL of your passwords using the Tools > Delete Browsing History option, and this will reset all password decisions back to prompt-- but doing this will wipe all of your passwords for all sites. If you're a technical user, there's a geeky way to get the prompt back for a specific page:

  • Get RegMon or ProcMon from SysInternals
  • Set a filter to watch the registry key containing the word "Storage2" without quotes.
  • Visit the page for which autocomplete information should be stored.
  • Watch which subkey within the Storage2 key is opened. 
  • Delete (or rename) that key to remove any stored passwords or "don't store" decisions. 

Case #7 occurs when your Administrator uses Group Policy to disable the AutoComplete feature. To see the Group Policy settings, click on Start and type gpedit.msc to launch the Group Policy viewer. Browse through to User Configuration, Administrative Templates, Windows Components, Internet Explorer. Check the policies for "Disable Autocomplete for Forms" and "Turn on the auto-complete feature for user names and passwords on forms." Alternatively, close IE, start Process Monitor, and filter for registry reads of keys containing the word FormSuggest.

Case #8 is something I didn't learn about until July of 2011. It turns out that most browsers (IE9, Firefox 5.01, Chrome 13) don't work properly when a login form is created dynamically using the createElement API. Here's a test page. Only Opera works properly with this test page. For what it's worth, if the test page injects a script-created form by injecting markup using innerHTML, it appears to work correctly in IE.

Case #9 is something I didn't learn about until June of 2012. If you copy/paste or drag/drop the text into the username box without ever typing any letters (even if you deleted them later), then you will not be prompted to save the password.

Note: If you see the prompt in IE9+ but it immediately disappears the problem is likely that your login page immediately navigated to a page on a different domain. Many of IE9+'s notification bars, including this one, go away automatically when navigating to a different domain.

If, on the other hand, you do see the Save Password prompt, but the password doesn’t seem to autofill, there are several possibilities:

  1. The website’s login page uses paths that contain unique or changing tokens
  2. The website's login page deliberately randomizes the name of the form fields
  3. Your stored passwords are being cleared between visits

The Forms password manager is designed to recognize when you’re revisiting a login form for which you’ve previously stored a password. When you enter a username for which you’ve stored a password, the password should automatically be filled in the appropriate box.

A key point here is that IE must recognize that this is a form for which you’ve stored a password. IE’s password manager takes into account the URL (specifically the hostname + folder path + filename, not including the query string or fragment) and the name of the form fields. If the website changes these values (for instance, it stores a session identifier as a “virtual” folder in the URL), then IE will not recognize a revisit the login form and will not fill the password. Similarly, if the website changes the names of the HTML input controls, IE will not fill the password. I have encountered several sites which suffer from one or both of these problems.

Lastly, it’s possible that your stored passwords are simply being deleted. IE includes a number of features that allow you to delete your browsing history, including your stored passwords. Make sure that you have the checkbox Delete browsing history on exit checkbox unchecked inside Tools > Internet Options > General . Also, if you use the Delete Browser History command, you should uncheck the Passwords checkbox or you will lose your stored passwords. Notably, the Preserve Favorites Website Data checkbox at the top of this screen will not preserve your form data, including passwords. (Interestingly, it's impossible for the feature to keep form data. Only URL hashes are stored in the registry, so the feature cannot determine whether a piece of stored form data belongs to one of your favorite sites).

Internet Explorer 11 Update

The IE team made significant investments in fixing password autocompletion for IE11. Of the list of "possible problems" above, IE11 resolves #2, #5, #8, and #9 as well as most cases of #4. IE's Password Manager now supports autocompletion for the majority of logon forms.

You might wonder: "Why does IE11 ignore the AUTOCOMPLETE attribute on login forms while continuing to respect the attribute on all other AutoComplete input elements (e.g. address, credit cards, phone #, etc) ?"

The answer is that Password Managers improve real-world security, and the IE team felt it was important to put users in control. Users rely on their password manager to permit them to comfortably use strong passwords. Password managers encourage strong, unique password creation per site, but unique, strong passwords are often difficult to remember and type on touch devices. If the browser doesn't offer to autocomplete a password, the user assumes that the browser is broken. The user will then either use another browser that ignores the attribute, or install a password manager plugin that ignores it. I'm an example of this myself-- until IE11, I used a weak password on the site that publishes my book because I couldn't convince them to remove the AUTOCOMPLETE attribute from their login form. Now, with IE11, that worry is gone and I can use a strong password on that site without a major hassle.

Troubleshooting Login Cookies

Other users have encountered problems where a website offers a “Remember me” checkbox but that checkbox doesn’t seem to work. There are a number of possible reasons for this:

  1. You checked “Remember me” while in IE’s InPrivate browsing mode
  2. Your cookie settings restrict the server’s ability to set persistent cookies
  3. Your browser zones configuration is incompatible
  4. Your browser isn’t patched
  5. The website’s security policy requires an occasional login
  6. The website’s cookies are being cleared

Problem #1 is simple enough-- “Remember me” features typically require the server to set a persistent HTTP cookie to store your authentication information. When you are browsing in IE8’s InPrivate Browsing mode, all persistent cookies are automatically downgraded to session cookies that expire on browser exit. Also, when the browser starts an InPrivate Browsing session, the cookie jar starts out empty for that session. So, you should not expect “Remember me” to work if you either are in an InPrivate session, or checked the box in such a session.

Problem #2 occurs if you’ve adjusted your cookie settings inside Tools / Internet Options / Privacy. If you’ve changed these settings from the defaults (or if the site is constructed in an unconventional way) the site may not be permitted to save persistent cookies at all. When this is the case, the site will not be able to set persistent cookies and hence the “Remember me” feature will not work.

Problem #3 occurs on Windows Vista and above, when you have configured one subdomain to run outside of Protected Mode (e.g. put it in the Trusted Zone) and another related subdomain to run inside of Protected Mode (e.g. left it in the Internet Zone). This isn’t terribly common, but might occur if you, for instance, put login.live.com in the Trusted Zone but didn’t put mail.live.com in the Trusted Zone. The root cause of this obscure problem is that Protected Mode and non-Protected Mode do not share cookies, and hence a cookie set by a site outside of Protected Mode will not be visible to a site running inside Protected Mode, and vice versa.

In some cases, this can lead to even worse problems. For instance, consider the case where you put www.google.com in the Trusted Zone and visit www.gmail.com . If you then try to log into GMail, you will be redirected endlessly, as the login host redirects you to the application host (since the login page has the cookie and believes you're logged in), and the application bounces you back to the login page (because the application doesn't see your login cookie). Servers can prevent such loops by passing querystring parameters when redirecting so the destination knows not to immediately redirect back in a loop.

Update: I wrote a longer post about problem #3 here.

Problem #4 relates to obscure cookie-related issues in IE7 which were fixed in subsequent patches. Ensure you have the latest updates for your browser using WindowsUpdate.

Problem #5 is that some sites (particularly secure sites) will require that you periodically (e.g. every week or month) re login  to help limit the risk of misuse of your credentials. Sometimes, sites will track which IP address you use to log in, and if your IP address changes (e.g. you move from one network to another with your laptop) your cached login cookies will be considered invalid.

These cases are tricky to troubleshoot because there’s no indication to the client (unless the server explicitly provides an indication) that you sent a legitimate stored cookie but security policy requires periodic re-login. You can usually only determine that this is the problem by using a network monitor (like Fiddler ). Unfortunately, even that form of troubleshooting is difficult because unless you happened to have Fiddler running at the time of the prompt, it’s usually too late (because the login form will often itself wipe your “outdated” cookie).

Problem #6 is the most common problem—the website’s cookies are simply being cleared. As noted above, there are a number of ways that this can happen: you may have IE configured to delete cookies on exit (see the checkbox Delete browsing history on exit checkbox unchecked inside Tools > Internet Options > General) . Or, perhaps you’ve deleted browser history manually using the Delete Browser History command. It’s also possible that your cookies are being cleared by another piece of software, for instance, security or privacy utilities.

Reporting Problems

If you find yourself encountering a problem with stored passwords, gathering the following information will help troubleshooters:

  1. What is the URL of the login page?
  2. Is the problem that you don’t see the “Save password” prompt?
  3. Or, is the problem that you do see the “Save password” prompt but it doesn’t seem to work?
  4. Or, is the problem that a “Remember me” box in the web page doesn’t seem to work?
  5. Have you added any sites to the Trusted Zone?
  6. Inside the Tools > Internet Options > Privacy screen, is the Default button disabled? If you click the Sites button, is the sites list empty?
  7. What addons are listed inside Tools > Manage Add-ons ? Do you have the “Windows Live Sign-in Helper” installed, for instance?
  8. Are you running any 3rd-party security or privacy utility software?
  9. If the problem is a “forgotten” login stored using “Remember me”—when did you last log into the website? Was that login from the same computer, in the same location?

While troubleshooting login problems can be quite tricky, in most cases problems are resolved by relatively simple configuration changes.

Until next time,

Eric Lawrence