7

IE11 dropped support for autocomplete=off for input type=password at both the form and element level.

Has anybody found a working solution to disable autocomplete under IE11?

Nicolas Barbulesco
  • 1,789
  • 3
  • 15
  • 20
Hofi
  • 945
  • 1
  • 6
  • 18
  • 11
    Have you checked [this](http://blogs.msdn.com/b/ieinternals/archive/2009/09/11/troubleshooting-stored-login-problems-in-ie.aspx)? In short, you're trying to revert what IE team thinks about as a fix. ) [Here](http://blog.gerv.net/2013/10/ie-11-ignoring-autocompleteoff/)'s one possible approach to circumvent it, I suppose, but that's quite the royal pain in the bottom area. ) – raina77ow Oct 07 '13 at 16:14
  • Thanks, but unfortunately that solution requires javascript be enabled whilst the autocomplete="off" would be pure HTML(5) – Hofi Oct 08 '13 at 08:37
  • 1
    just for the record, the linked in solution does not work if listening on form submit event, that time is too late, IE will already confirm the password save, you should do the trick in the (submit typed) button onclick handler! – Hofi Oct 08 '13 at 12:02
  • 3
    You must mean a tricky workaround, not a solution. – Nicolas Barbulesco Jan 08 '14 at 13:11
  • 1
    Just so I understand you correctly; you want to re-enable autocomplete for passwords? So that if a user types in the first character, the browser spits out the rest of the password? – Sampson Jan 13 '14 at 16:06
  • according to http://msdn.microsoft.com/en-us/library/ms533486%28VS.85%29.aspx "As of Internet Explorer 11, the autocomplete property is no longer supported for input type=password fields." There one and only example of how to use autocomplete: "" Got to love it.. – Jdahern Jan 16 '14 at 01:50
  • For the record, the reason I want to disable autocomplete of a password field is for when creating a new user. – Petah Sep 23 '14 at 05:03
  • This answer does the trick: http://stackoverflow.com/a/32281293/355438 – Ilya Serbis Feb 08 '16 at 07:59

5 Answers5

7

You're much better off solving the problem of security with two-factor authentication. Hacking around the browser will (a) only work in the short-term (password managers are getting better at handling these kinds of approaches), and (b) often lead to accessibility issues, which can cost you a lot more users than your fear of legitimate password leakage. If you work in a large organization, users of assistive technology who have a tough enough time with your browser hacks can end up filing a lawsuit. (I am not speaking to this hack in particular, but generally speaking working against the browser hurts assistive technologies)

Two-factor authentication, even a sloppy implementation that just asks for something like middle name, then sets a cookie ("this browser is now allowed access without 2FA for a month"), makes it immensely more difficult for a random hacker to gain unauthorized access to an account, and keeps things better off for the users, especially those using screen readers or other assistive technology.

Disabling password managers, on the other hand, tends to lead to easy-to-type passwords rather than strong passwords. Using LastPass or similar, I can have a 24-character password (and LastPass can probably fill in fields you're trying to protect with hacks, fyi) that I would never hope to remember, and a different password for each site. When I have passwords I have to remember, they tend to be two words strung together with a symbol, such as "Dogs+Knife".

Nerdmaster
  • 4,287
  • 1
  • 22
  • 16
  • That's a nice piece of advice despite not being an ansert to the original question. What if I accept 3 different passwords in the app and it's confusing to the users when the browser auto-completes a totally unrelated password field with their main password? – naugtur Jul 24 '14 at 08:06
  • That's a problem that doesn't really have a great solution. USAA banking does something like this. It has a login and a PIN area. LastPass works great for the login, but tries to autofill the same password into the PINfield - even though the field has a totally different name and USAA puts "autocomplete=off". So long story short, you still can't really stop password managers, which in this case is very unfortunate. The pin field is a wonderful case where turning it off makes sense, since it's a very simple 6-digit field. I wish I had a better suggestion for these edge cases :-/ – Nerdmaster Jul 24 '14 at 16:52
1

This is a work-around, not best practice.

IE 11 will autocomplete any input type="password". BUT it will only populate the first one. So what I have done is this

<div style="display:none;">
    <input type="text" id="my_username"/>
    <input type="password" id="my_password"/>
</div>              
<asp:Login ID="Login1" runat="server"
    SkinId="LoginDefault" LabelStyle-Font-Bold="true"
    DisplayRememberMe="False"
    DestinationPageUrl="~/CheckPassword.aspx">

    <LoginButtonStyle CssClass="btnEntry" />
    <LabelStyle Font-Bold="True" />
</asp:Login>

Now if you notice the first one has a style of display:none. Which allows IE 11 to autocomplete it, but the user doesn't care, because they don't see that. I know this is kind of a hack, but it works.

halfer
  • 19,824
  • 17
  • 99
  • 186
DeadlyChambers
  • 5,217
  • 4
  • 44
  • 61
  • I don't understand what you say about IE 11. It seems to be contradictory. – Nicolas Barbulesco Jan 08 '14 at 13:07
  • IE Ignores the autocomplete attribute on the password field. So if anyone logs into a machine and the password has been stored hitting the first key in their name will allow you to login to their account. IE believes the user should turn the setting off not the developer. So in order to circumvent IE 11 ignoring the autocomplete just hide the first password field so the user isn't able to automatically login. Does that make more or less sense? I am not sure I understand your question. – DeadlyChambers Jan 09 '14 at 22:32
  • I don't understand what you say. But it is not a big deal, because IE is right in this matter — for once. – Nicolas Barbulesco Jan 11 '14 at 17:00
  • 2
    How is IE right in this matter? I know they think there top in security, but it should be up to the dev to determine if auto complete should be allowed, not the brower. – Jdahern Jan 16 '14 at 01:50
  • The battle isn't lost for me. I figured out a solution to my security issue. I think the user actually lost on this decision. – DeadlyChambers Jan 30 '14 at 21:15
  • 33
    What's the point in doing this? It doesn't improve the security (the password is still stored and just as easy to extract as before) and it's annoying the legitimate user. In a way it's even harmful for security: The user is lead to assume that the password isn't stored but it actually is. They might make bad security decisions based on that. – CodesInChaos Apr 17 '14 at 13:01
  • 2
    The point is IE 11 will store passwords so if you hit one key say a. Then user abbiegal89 and her password will automatically be put in there. The people using our web app share computers. So there could be 15 people sharing the same computer, one could be an admin. So if someone were to type in the first letter of any users name they could log in as them. That is the kind of security I am worried about. If you can figure out a better way be my guest. – DeadlyChambers Apr 17 '14 at 13:53
  • This is for a healthcare web app that has multiple users that share a computer. IE has made it possible for anyone to log in as any user just by typing in the first character of any username that has logged in. That CANNOT happen. I agree to a certain extent, but in this case IE has created a security issue. – DeadlyChambers Jun 10 '14 at 16:58
  • 3
    @DeadlyChambers Still a user realm problem. Use private browsing if you are on a public terminal, or better yet, if it's a kiosk you can configure that for them. Or is IE11 also saving passwords when in private mode? – gonchuki Jun 11 '14 at 00:38
  • 5
    @DeadlyChambers trying to work around a client behavior using server-side techniques does not security constitute. The next version of IE will disable your workaround, or Chrome will also ignore that attribute and you'll have to try and pile another workaround, or Firefox will just plain ignore any hidden fields.Meanwhile, you will feel secure in the knowledge that you've "solved" a problem that is not a problem of your website, but a problem of the client setup. – Franci Penov Jun 11 '14 at 17:07
  • 5
    IE did not create a security issue. A simple keylogger installed on that shared computer will expose the same issue. If you want to make your website secure, adopt two-factor authentication. Or force each user to have their own Windows account. In fact, I would argue that since this is a health application, the fact that you are relying on shared Windows account is most likely already in violation of some regulations. – Franci Penov Jun 11 '14 at 17:12
  • 6
    People - in an enterprise setting like a hospital, employees are not able to install password managers and the like. Likewise, IT staff can configure the browsers they use to disable autocomplete. That said, the witch hunt and downvoting is really unbecoming. There are many instances in which disabling autocomplete is a very valid requirement. In fact, in a healthcare setting, it may be seen as a direct impact of federal law. Asserting that these are user preferences and should therefore never be abrogated is immature and demonstrates a poor understanding of how regulation impacts design. – Thomas W Tupper Aug 01 '14 at 20:50
  • @ThomasWTupper: There's nothing immature in defending /my/ control over what /my/ computer does. Would you call it childish to install a virus scanner software in an attempt to retain control over one's own computer? – T-Bull Feb 10 '15 at 11:11
  • 1
    The autocomplete=off feature was originally designed to safe non-adept users from their own incompetence in the rare case of exceptionally sensitive information being entered on a website, like on banking sites. (The actual mistake in that is to use an utterly insecure technique like the www for banking in the first place.) But then, numerous websites have abused the feature, and soon there was hardly any website left where auto form completion was still available.I myself wrote an autocomplete=on Greasemonkey script for that reason. It is a matter of self-defense against web design stupidity. – T-Bull Feb 10 '15 at 11:12
  • 2
    T-Bull do you want to comment on the enterprise level implications of this, or do you simply want to rant? My point was and is that in some use contexts this functionality must be disabled, for security and also for regulatory compliance. You said nothing at all about the substance of my statements, you simply went on a rant about your 'right' to 'defend yourself' against 'web design stupidity'. In so doing you missed the actual points I made. Do you care to add something with respect to those concerns? – Thomas W Tupper Feb 10 '15 at 18:40
1

I'm a bit late to this, but the cleanest approach (at the time of writing) seems to be making users submit their username and password in different pages, i.e. the user enters their username, submit, then enters their password and submit. The Bank Of America and HSBC Bank websites are using this, too.

Because the browser is unable to associate the password with a username, it will not offer to store passwords. This approach works in all major browsers (at the time of writing) and will function properly without the use of Javascript. The downsides are that it would be more troublesome for the user, and would take 2 postbacks for a login action instead of one, so it really depends on how secure your website needs to be.

PS: Firefox will be following IE11's lead and ignore autocomplete="off" for password fields, as per this 'bug report' which is marked VERIFIED FIXED.

JW Lim
  • 1,794
  • 3
  • 21
  • 41
  • 7
    „it really depends on how secure your website needs to be” – and stopping password managers from working will make the site _less_ secure for any user caring enough. – Jacek Konieczny Jun 10 '14 at 18:22
  • @JacekKonieczny You're thinking about normal websites though. What about security-critical web applications for large corporate entities? There are plenty of companies whose IT policy is to never use password managers for company applications. Especially when you can view the **clear text** password with administrative privileges on the computer. – JW Lim Jun 11 '14 at 00:32
  • 5
    @JWLim security critical websites should be encouraging good practices. Consider fixing your security policy, allowing password managers (and thus encouraging more secure passwords) and 2FA while you're at it. – mikemaccana Jun 11 '14 at 06:57
  • @mikemaccana Let's put 2FA aside for now. If users were allowed to save passwords for company applications, what happens if someone gains access to the user's computer, through hacking, viruses, the user leaving their computer on while away, etc? That person can now view the passwords of said user in clear text via the browser's password manager, and can access all company websites that the user had access to. Is that really what you'd call good security practice? – JW Lim Jun 11 '14 at 07:26
  • 11
    It ultimately should be up to the user if he wants to store a password or not. It should NOT be up to the website operator. Firefox asks if to store the password, it doesn't do so automatically. So it's the user's decision for every site if to store the password. I have `pwgen 24` passwords for most sites, each differently, and I think that using the password manager increases my overall security instead of using the same password everywhere. – Martin C. Jun 11 '14 at 07:39
  • @MartinC. I agree it should be up to the user for normal websites, but in corporate environments I think the company should also be allowed to decide if they want to leave it up to their employees to practice good security. We all know how many users use different passwords for every site. Even with password managers offered by the browsers, many users still use same passwords. – JW Lim Jun 11 '14 at 07:53
  • Anyway, the question was how to stop the browser (IE11) from saving passwords. It is not a discussion on whether users should be allowed to do so or not. I don't think continuing this discussion in the comments is a good idea. If someone wants to discuss this further via another avenue (such as chat) and convince me that this is bad practice, I will be glad to oblige. – JW Lim Jun 11 '14 at 07:56
  • 1
    @JWLim If an attacker has full control of the a user's system, it's already too late - weak passwords make that more of a possibility. – mikemaccana Jun 11 '14 at 08:44
  • 1
    @JWLim 2FA is intended exactly to solve the issue of "what if someone hacks my computer or steal my stickies I write all my passwords on and gets all my passwords". You can't say "put 2FA aside and tell me how to solve a problem that 2FA solves" – Franci Penov Jun 11 '14 at 17:15
  • 1
    This doesn't prevent external password managers. LastPass holds all kinds of data, and can span multiple pages in some cases I've used it on. The hacking / fighting the browser / user behavior will only ultimately make your job harder, the end user who doesn't know about LastPass frustrated, and potentially add security holes as you get more and more unorthodox trying to fight these systems. – Nerdmaster Jun 13 '14 at 16:49
  • 1
    I agree with @MartinC. A site should not have that control. It is ultimately a user preference. If it is company policy, then tell the employees about it and tell them not to use a password manager. Heck, throw a message on your site's login form saying "It is against company policy for you to use a password manager to store passwords for this site." I have never run across a single site that disabled autocomplete and been happy about it or thought it was a good idea. – Joe Zim Jun 19 '14 at 14:00
  • 2
    @DeadlyChambers is correct on this one. The chorus of people sounding off on this don't understand the law and they don't understand federal requirements. I build health care apps used in hospitals, and there are serious patient privacy issues tied up in this, issues which not only can cost facilities hundreds of thousands of dollars for violations, but which can place caregivers and patients at risk. In a healthcare setting, not only are such user conveniences unwise, they verge on being unlawful. – Thomas W Tupper Aug 01 '14 at 20:28
0

You can insert hidden input after user name input.

Arsen Khachatryan
  • 93
  • 1
  • 9
  • 2
    As with many other responses, this doesn't do anything to prevent external password managers like lastpass. It can memorize just about any field, hidden or otherwise. – Nerdmaster Jun 13 '14 at 16:52
0

You need to have different pages for username and password. This approach is used by google too.

Google Sign In Screen

Arsen Khachatryan
  • 93
  • 1
  • 9