28

I created 2 login pages of same domain.

  1. www.example.com/login.cfm
  2. www.example.com/newLogin.cfm

I put the form name different for 2 forms with in these two page. Also I put autocomplete = 'off' for the second form and for the text fields within that form.(But it is on for first form ).

Now if I save the username and password at the time of login from www.testDomain.com/login.cfm in browser, then the list of usernames are auto populating in the username field of second login page even if the auto Complete is off. I need to block this for security reasons. Is there any way to do this? I am using FireFox V21.

Matthew Lock
  • 13,144
  • 12
  • 92
  • 130
Deepak Kumar Padhy
  • 4,128
  • 6
  • 43
  • 79
  • As this is a browser issue, what's it got to do with ColdFusion? – Adam Cameron Jul 22 '13 at 06:33
  • possible duplicate of [Is there a W3C valid way to disable autocomplete in a HTML form?](http://stackoverflow.com/questions/582244/is-there-a-w3c-valid-way-to-disable-autocomplete-in-a-html-form) – Zaheer Ahmed Jul 22 '13 at 06:36
  • possible duplicate of [autocomplete ='off' is not working when the input type is password and make the input field above it to enable autocomplete](http://stackoverflow.com/questions/17719174/autocomplete-off-is-not-working-when-the-input-type-is-password-and-make-the) – Álvaro González Jul 22 '13 at 06:47
  • who ever suffer from the same, submit feedback https://qsurvey.mozilla.com/s3/FirefoxInput/ – JavaSheriff Aug 20 '19 at 00:32

20 Answers20

38

This is the cleanest solution I have found to keep Firefox from auto completing.

 <!-- The text and password here are to prevent FF from auto filling my login credentials because it ignores autocomplete="off"-->
 <input type="text" style="display:none">
 <input type="password" style="display:none">

Add this code snip-it above your input of type password.

As far as I can tell Firefox is looking for an input of type Password, and filling in the password and then adding the username to the input of type text above it. Without a name or an id the inputs don't get added to the post, but this is still a hack.

Bob The Janitor
  • 20,292
  • 10
  • 49
  • 72
  • 3
    This worked great for me, I can't believe this is August 2015 and such a hacky approach is necessary, common HTML standards fix this. – edencorbin Aug 17 '15 at 22:15
  • 1
    I was just about to say the same thing, so we're beginning to have to hack modern browsers as we did back in IE6 days, FF needs to step up... this is STILL a problem on my FF – Prof Apr 06 '16 at 08:07
  • Lol, still a problem, ^ that was me ^ hahaha – Prof Nov 16 '16 at 12:40
  • 2
    I can't believe this. It is crazy but it works as at 24 June 2017. I have tested any other solution but the password was still auto completing but now it is solved. – John Max Jun 24 '17 at 22:26
  • Firefox 61 here and it still ignores the autocomplete attribute on password fields. This solution works for me but the hidden input fields need to be *inside the form*. – But those new buttons though.. Aug 23 '18 at 20:29
  • Firefox 110.0.1 (64-bit) here and it still ignores the ```autocomplete="off"``` attribute on password fields. – Andrew Tvorch Mar 22 '23 at 14:45
36

$("#CVV").on("focusout", function() {
    if ($(this).val() == "") {  
      $(this).attr("type", "text");
    }   
});
<input type="text" name="username" class="input" ID="CVV" onfocus="removeErr('CVV'); $(this).attr('type', 'password');">
3rdthemagical
  • 5,271
  • 18
  • 36
albert.garipov
  • 455
  • 4
  • 6
13

You all should try this attribute :

<input type="password" autocomplete="new-password" />

If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password".

See the documentation there : https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#Preventing_autofilling_with_autocompletenew-password

PulsarFox
  • 131
  • 1
  • 7
  • 1
    Links to external resources are encouraged, but please add context around the link so your fellow users will have some idea what it is and why it’s there. Always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline. See: [How to anwser](https://stackoverflow.com/help/how-to-answer). – Eduardo Baitello Aug 13 '19 at 12:43
  • 1
    autocomplete="new-password" is still buggy in firefox 68, it works if you navigate to a page on a different domain, but moving to another page on the same domain will trigger a 'save password' dialogue box. – SS64 Aug 23 '19 at 07:43
  • 1
    Working on FF 75.0b12 This to me seems like the better solution, just a browser support issue. – AdheneManx Apr 09 '20 at 04:05
  • Doesn't work in Firefox Version 104.0.2 (2022) – JavaQuest Sep 12 '22 at 14:15
2

Firefox version 61 this seems to be enough to disable autocomplete in forms:

<input type="password" hidden />

All inputs after this one at the top of the form are ignored.

Darko Tasevski
  • 396
  • 4
  • 11
2

Nothing worked for me for the password field so I'll share my trick

<input name="password" type="text" onkeydown="this.type='password'">

I believe it is still secure and works on Chrome, Firefox, other

RicardoVallejo
  • 793
  • 7
  • 11
1

I was encountered this issue for a long time. Firefox was kept input values even page reload. Setting autocomplete attribute to off did not solve.

Form caching is a really useful mechanism for the user experience. But, in the small percentage of use-cases like translating values of textboxes or texareas to other language, these gave me headache.

To resolve this, just simply reset the form after page was loaded as

 $('form').trigger("reset");
Cataclysm
  • 7,592
  • 21
  • 74
  • 123
  • 1
    Thank you. This fixed the issue I was having with a huge form for creating new user accounts with accountID and password fields which are both then used to login and every time the "new account" form was accessed, the current user's accountID and password were autofilling in the event the user stored their credentials in the browser. – butterednapkins Mar 05 '19 at 15:10
0

I've noticed this behavior also lately - Firefox only; there's seems to be a problem with the 'autocomplete="off"' attribute.

Used to work great up until a month ago - and broke up around the time Firefox version 30.0 was released.

Still works great on Chrome + IE;

yarg
  • 679
  • 6
  • 11
  • There is a bug report, but some developers seem to say it's a **feature**, because many websites use `autocomplete="off"` incorrectly. – Daniel Cheung Mar 06 '16 at 15:31
  • Firefox overrides autocomplete=off for login forms - @see https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields – yarg Jan 17 '18 at 09:50
0

https://bugzilla.mozilla.org/show_bug.cgi?id=956906

http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0015.html

Autocomplete has been disabled for password type input fields. The above links mention that respectively for FireFox and IE, but I see that setting autocomplete to off for form too is not working.

0

This is working for me:

<input type="text" name="username" value=" " onclick="if(this.value == ' ') this.value=''" >

Click here for more info about this.

zavero.kris
  • 21
  • 1
  • 6
0
Try this :
<input type="password" style="display:none">
<input type="password" name="password">

Type must be the same. The hidden password will be fill instead of real password input.

If it's a new password (or reseted) use autocomplete="new-password" instead of autocomplete="off".

Hope it helps.

ahammani
  • 83
  • 1
  • 5
0

I tried all of the above with Firefox 52 and nothing worked. I did get it to work with jQuery though and replacing the value with the original value, or:

jQuery(window).load( function () {
    email = jQuery('#auth_user_email');
    email.prop('value', email.attr('value'));
});

where in jQuery the prop is the current value in the document and attr is the original when the document is first retrieved/loaded. I used the load function because it runs after the ready function and I believe definitely after the autocomplete overwrites the input value. you can do the same thing with the password input also.

lucas
  • 47
  • 6
0

A way to Firefox don't find those fields is to change their type to hidden before the post.

You can use a jQuery or JavaScript to set that on onclientclick in your submit button.

Example: <script type="text/javascript"> function setHidden() { $('.input').prop('type', 'hidden'); } </script>

<input type="text" name="username" class="input">
<input type="password" name="password" class="input" >
<asp:Button ID="ubtnLogin" Text='OK' runat="server" OnClick="btnLogin_Click" OnClientClick='setHidden();' />

Just remember to clear your browser's cache before testing or use the private mode (CTRL+SHIFT+P).

CPJ
  • 128
  • 2
  • 6
0

thanks to the idea of albert.garipov, i made a solution that mimics the functionality of the type password. this doesn't show the password on input

<input type="text" id="password" onkeyup="OnChangePassword()">

function OnChangePassword()
{ 
  if ($("#password").val() == "") {
      $("#password").attr('type', 'text');
  }
  if ($("#password").val() != "") {
      $("#password").attr('type', 'password');
  }
}
0

Just put a random value in autocomplete.

Disregard my old suggestion as it is not a good practice.

coffeemesh
  • 63
  • 9
0

I know quite an old question. But adding autocomplete="off" in the form tag might help

works for firefox now* (*98.0.2 (64-bit))
  • I [searched through bugzilla](https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&short_desc_type=allwordssubstr&short_desc=autocomplete&resolution=FIXED) and found no indication that this behavior has been changed. Your answer could be improved by referencing a changelog or other documentation to support your claim. – Besworks Apr 05 '22 at 18:36
  • Sure will do... – SANJAY BEEDI Apr 07 '22 at 09:41
0

This behavior of ignoring autocomplete on login fields was introduced intentionally.

According to this article on MDN:

You can use the autocomplete attribute value of new-password to inform the browser not to fill the password field in your sign up form. This also provides a hint to let the browser suggest generating a strong password.

<form>
  <input type="text" name="username" placeholder="enter your username" autocomplete="username">
  <input type="password" name="password" placeholder="enter your password" autocomplete="password">
  <button> Sign In </button>
</form>

<form>
  <input type="text" name="username" placeholder="create a username" autocomplete="username">
  <input type="password" name="password" placeholder="create a password" autocomplete="new-password">
  <button> Sign Up </button>
</form>

There is no equivalent autocomplete value for new username fields. Firefox heuristically determines what should be classified as a username and whether it should be autofilled or not. The input[name=username] near the new-password field should be detected automatically and ignored.

Besworks
  • 4,123
  • 1
  • 18
  • 34
0

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

If a browser keeps on making suggestions even after setting autocomplete to off, then you have to change the name attribute of the input element.

change the name attribute

<input type="text" name="user_name" class="input" autocomplete="off">
<input type="password" name="pass_word" class="input" autocomplete="off">
-1

I realize that this is an old question, but as it's still relevant on Google searches, I believe it's important to present another view which opposes a lot of the answers here which, while well intentioned, are somewhat short-sighted.

Preventing auto-fill for login inputs can lead to a lot of problems. There are no benefits and significant downsides. Humans are bad at remembering credentials, leading to people without password managers using the same passwords on multiple (often critical) sites. If one of these sites is compromised, there's a very good chance that an attacker can log into other sites with the same credentials. Tools like LastPass, Bitwarden, Dashlane, Onepassword, etc. all exist for a good reason: they help keep the web a safer place for the majority of users by facilitating the use of separate passwords per web site.

Mozilla, Google and Microsoft are all on-board with this and have purposely decided to ignore the autocomplete="off" directive in many cases where it is likely to be more beneficial, in the long run. For further details about this, I'd recommend taking a look at the following articles from Mozilla, Google/Chromium, Microsoft and the Web Hypertext Application Technology Working Group:

Now, there may be cases where you're writing an internal application in an industry with strict compliance requirements. It might seem like a good idea to disable auto-fill for login forms in this environment given the added potential for sharing passwords if left alone. My answer to that would be that this is out of scope for the front-end web developer, and should fall to the desktop experience and the IT operations teams.

There are many ways that IT departments can enforce controls on workstations to prevent automated password sharing. Group Policy, SCCM, least-privilege account provisioning, etc. are all just the tip of the iceberg, and they've far more robust than attempting to tell the user-agent to disable autocomplete when it's not designed to function that way.

tl;dr: Please take the time to understand the platform you're developing for and don't work around the specs to disable autocomplete.

bshacklett
  • 1,802
  • 5
  • 23
  • 45
  • Your assumptions are quiet wrong - I'm writing an e-learning application - this is used in a classroom - in each lesson a different group of students use the same machines (and browsers) to run the web-application. They are also tested using this application - which means that auto-complete has to be disabled completely all-over (not only in login screen). I think that the auto-complete feature should be completely controlled by the application. – yarg Jan 29 '18 at 13:57
  • Not all forms with password fields are login forms. My application has both a login form and a registration form (which I believe is not so unusual ;-). When registering a new account while having a saved login password, it makes no sense to to autofill the saved login password in the registration form. – chris Jan 29 '18 at 14:56
  • @chris I would argue that that's a problem for the tool using the autofill API to solve. – bshacklett Jul 24 '19 at 15:45
  • @yarg: If those machines are in an environment where testing is taking place, those responsible for the upkeep of the systems should be maintaining strict control over what's installed on them. There's no reason why the application should need to disable auto-fill, because there should be no auto-fill facility on those machines in the first place. – bshacklett Jul 24 '19 at 15:50
  • Why do I encounter a lot of cases where an existing link/article/page is removed from Microsoft website? That feels like a breaking change. BTW, up-voting, because of the links referenced. Thanks. – Ardeshir Izadi Nov 28 '20 at 11:33
-2

Use autocomplete="off" tag at the end of your input tag:

For ex.

<input type="text" name="username" autocomplete="off" />
Sachin Sanchaniya
  • 996
  • 1
  • 8
  • 16
-4

Add autocomplete="off" to your form tag, as documented in the Mozilla document

Check the following link for more information

How to Turn Off the Autocompletion Feature

Arun Bertil
  • 4,598
  • 4
  • 33
  • 59