Disable browser 'Save Password' functionality

Question

One of the joys of working for a government healthcare agency is having to deal with all of the paranoia around dealing with PHI (Protected Health Information). Don't get me wrong, I'm all for doing everything possible to protect people's personal information (health, financial, surfing habits, etc.), but sometimes people get a little too jumpy.

Case in point: One of our state customers recently found out that the browser provides the handy feature to save your password. We all know that it has been there for a while and is completely optional and is up to the end user to decide whether or not it is a smart decision to use or not. However, there is a bit of an uproar at the moment and we are being demanded to find a way to disable that functionality for our site.

Question: Is there a way for a site to tell the browser not to offer to remember passwords? I've been around web development a long time but don't know that I have come across that before.

Any help is appreciated.

Fitly

You should provide a greasemonkey-script so people can re-enable it. I don't think users like to be forced to type the password every time... – Meir

The question deserves an upvote for being useful and clear. On the other hand i don't want people to find a solution to this "problem". – Cecillececily

This is not always a "problem". I came here because firefox prompts to save a password for a form that contains WiFi/SSID password, not a login username/password form. It is very annoying and I want do stop it. – Epithelium

If the information is that critical, it should be protected by more than just a password. – Hospital

One way it seems to work is not to use <form>. If you are using javascript to send the data (XHR), then you don't need it. I wanted to disable in a system that uses "one-time-password" authentication (no reason to store it). For user/pass authentications I wouldn't recommend to disable that feature. – Sella

Probably you need to loose the grip on the authentication method you are familiar with and let it go if it really contradicts the requirement. Enforcing security policy with breaking the other security policy does not make system any more secure. – Cowpea

You should be Encourageing the use of password managers by setting autocomplete= tag correctly. That is the way to improve security. – Cockfight

@Cockfight I imagine a user would be more encouraged to use a password manager if they are not prompted whether they want to save a one-time access code. Unfortunately most browsers no longer let autocomplete=off disable the password manager. One of the rationales is that autocomplete=off is never supposed to have anything to do with password managers, which is a valid point, but then there should be something specifically for this purpose. – Inflated

@ImperishableNight you should use autocomplete="one-time-code" as shown here. twilio.com/blog/… – Cockfight

@Cockfight Wow, I didn't know the autocomplete= tag accepted so many different values beyond "on" and "off". I guess it's not a valid answer for this specific question, but some "duplicates" of this question could surely benefit from a link to developer.mozilla.org/en-US/docs/Web/HTML/Attributes/… . – Inflated

github.com/noppa/text-security – John

Answer 1

I'm not sure if it'll work in all browsers but you should try setting autocomplete="off" on the form.

<form id="loginForm" action="login.cgi" method="post" autocomplete="off">

The easiest and simplest way to disable Form and Password storage prompts and prevent form data from being cached in session history is to use the autocomplete form element attribute with value "off".

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

Some minor research shows that this works in IE to but I'll leave no guarantees ;)

@Joseph: If it's a strict requirement to pass XHTML validation with the actual markup (don't know why it would be though) you could theoretically add this attribute with javascript afterwards but then users with js disabled (probably a neglectable amount of your userbase or zero if your site requires js) will still have their passwords saved.

Example with jQuery:

$('#loginForm').attr('autocomplete', 'off');

Nalepka

Just a quick comment, since this is changing, HTML5 adds the autocomplete attribute to the spec, so it is valid now. – Equipotential

firefox (3.6.15) doesnt seem to be regarding the autocomplete="off" at all. I tried adding that to both the form and the password field, but it still fills the pwd when i press tab on the username field. I alos tried changing the name attribute of the pwd field to something else, but looks like it uses the type="password" attribute (though i read it matches the 'name' attribute). That too doesnt work. Any thing else i can try? – Horsemanship

You can use the Chrome Autocomplete=On extension to defeat this :) chrome.google.com/webstore/detail/autocomplete-on – Recency

Just FYI, Microsoft decided that Internet Explorer 11 will no longer honor autocomplete="off" for input type="password" fields. msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx – Lahnda

but I DO want autocomplete on my form, and DON'T want the browser to save show the "save password" popup. – Passion

Just as @JWLim mentioned IE 11 dropping support for disabling password save functionality, so is Firefox. bugzilla.mozilla.org/show_bug.cgi?id=956906 – Eupheemia

@GregoryCosmoHaun Thanks for the info. It really does seem like the browsers are taking more and more power away from us developers :/ As far as I know we can still stop them from saving passwords if you seperate the 'Username' and 'Password' fields though. I've mentioned this in my answer below. – Lahnda

yes, does not work for Chrome. No matter what the popup comes up. – Duodenal

Firefox (unfortunately) followed Microsoft's lead and "removed" the autocomplete support as well. For details see comment 100 in the following issue discussion: bugzilla.mozilla.org/show_bug.cgi?id=956906 – Leper

Now, not work for Firefox 38+ mozilla.org/en-US/firefox/38.0/releasenotes – Sural

This is ignored by most modern browsers guys... caniuse.com/#feat=input-autocomplete-onoff – Townsfolk

So what would be the proper answer to this question? Despite 321 up-votes, this answer doesn't work. – Aftonag

Answer 2

In addition to

autocomplete="off"

Use

readonly onfocus="this.removeAttribute('readonly');"

for the inputs that you do not want them to remember form data (username, password, etc.) as shown below:

<input type="text" name="UserName" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

<input type="password" name="Password" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

Tested on the latest versions of the major browsers i.e. Google Chrome, Mozilla Firefox, Microsoft Edge, etc. and works like a charm.

Rosemarie

@KishoreSahas I have just tested on Firefox 49.0.1 and and seen that it is working as on the previous Firefox versions. – Byng

@KishoreSahas Could you please post your code so that I can check? – Byng

@Murat Yıldız: I have to implement the same and I followed your code.It is working fine for me in all browsers. Thank you ! – Seger

@Seger I am happy that it was helpful for you :) – Byng

I just tested this and it didn't work for Firefox (52.0) unfortunately. It let me save the password at my first login, and let me log back in with the saved login a second time. After that, it did prefill it when I tabbed to the password field sometimes, but other times not (not sure what's up there). I see the password in "Saved Logins..." area and you can have it show you the password there. It did seem to work for Chrome (56.0). – Zigmund

Just tested Mozilla Firefox 52.0, Google Chrome 57.0, Microsoft Edge 38.1 and working like a charm!.. – Byng

@mikato Maybe you have applied something wrong, please retry again and let me know if it is working... – Byng

@MuratYıldız Strangely it seemed that my own Firefox web browser could save the password still, but other people also with Firefox said that they could no longer save the password. But now, several days later, I also cannot save my password. So I guess it worked and somehow my browser had a delayed reaction. That might make me blame caching, but it seems strange still. – Zigmund

@mikato I am happy that your problem has finally been solved and you make it work properly :) – Byng

There can be an error in Safari mobile as this answer is fixing it #3030 – Incurable

@Incurable I am happy that it helps to fix the problem ;) Thanks for feedback. – Byng

Windows Firefox 57.0.2 (64-bit) is still suggesting to save password after I implemented this. – Feast

@PanuHaaramo It does not matter if the browser cannot remember user credentials for the next logins... – Byng

just tried to use this method and it only works in Chrome. it does not work in Opera, Firefox or Internet Explorer – Lofton

@Lofton I have just tested again for you by using the following browsers: Chrome Version 72.0.3626.109 (Official Build) (64-bit), Firefox Quantum 65.0.1 (64-bit), Firefox Developer Ed. 66.0b7 (64-bit), Internet Explorer 11 and still working like a charm!.. – Byng

@murat-yildiz well i don't know what to tell you. i tested it with the current release versions of the browsers i listed (on windows 7), and it failed to work on Opera, Firefox, and IE11. the only browser it worked for me on was Chrome. maybe you could provide the full html code of your working version so i can test again? – Lofton

<input type="password" name="Password" autocomplete="off" readonly onfocus="this.removeAttribute('readonly');" style="background:#fff; cursor: text;" > The solution is great no doubt about it. But if we implement it, password frield looks disable so after these changes I think this solution does not need further changes. We just need to add some background white color and cursor look. – Hubbub

@AsadNaeem I might depend on the styles used in your page. Because the page where I use this code has no disabled look or effect and everything works like a charm on the given browser versions. – Byng

@MuratYıldız I am using Chrome. So it might be the browser version. – Hubbub

in firefox browser 84.0b8 (64-bit) version not working. – Meridithmeriel

it does not work in Chrome Version 115.0.5790.171 – Keturahkeung

Answer 3

I had been struggling with this problem a while, with a unique twist to the problem. Privileged users couldn't have the saved passwords work for them, but normal users needed it. This meant privileged users had to log in twice, the second time enforcing no saved passwords.

With this requirement, the standard autocomplete="off" method doesn't work across all browsers, because the password may have been saved from the first login. A colleague found a solution to replace the password field when it was focused with a new password field, and then focus on the new password field (then hook up the same event handler). This worked (except it caused an infinite loop in IE6). Maybe there was a way around that, but it was causing me a migraine.

Finally, I tried to just have the username and password outside of the form. To my surprise, this worked! It worked on IE6, and current versions of Firefox and Chrome on Linux. I haven't tested it further, but I suspect it works in most if not all browsers (but it wouldn't surprise me if there was a browser out there that didn't care if there was no form).

Here is some sample code, along with some jQuery to get it to work:

<input type="text" id="username" name="username"/>
<input type="password" id="password" name="password"/>

<form id="theForm" action="/your/login" method="post">
  <input type="hidden" id="hiddenUsername" name="username"/>
  <input type="hidden" id="hiddenPassword" name="password"/>
  <input type="submit" value="Login"/>
</form>

<script type="text/javascript" language="JavaScript">
  $("#theForm").submit(function() {
    $("#hiddenUsername").val($("#username").val());
    $("#hiddenPassword").val($("#password").val());
  });
  $("#username,#password").keypress(function(e) {
    if (e.which == 13) {
      $("#theForm").submit();
    }
  });
</script>

Guarino

That looks like a good solution. It makes sense since the form that you send down does not itself include a password. I suppose to be sure you could have two forms, the first one just to ensure that the username and password are visible in all browsers. – Seesaw

i like your solution and implemented a similar on my site, is ridiculous how at today, browsers dont offer a simple way to solve this. – Penta

Not sure if it's because I'm stuck using jquery 1.6, but the above jquery only worked after wrapping inside a $(document).ready(function(){ }); – Schaumberger

The only correct soultion is this since some browsers wont accept autocomplete="off" any more! – Lollard

This was working fine for me in chrome, but recently is started again prompting for save password – Caustic

Breaking the security feature with amateur grade code is a horrible solution in the fact. – Cowpea

One problem with this i see is the hidden password shows the actuall password text in the browser. – Scudo

i've just tried this method on chrome,opera and internet explorer and it seems to work, but it doesn't work with Firefox unforuntately – Lofton

Answer 4

Well, its a very old post, but still I will give my solution, which my team had been trying to achieve for long. We just added a new input type="password" field inside the form and wrapped it in div and made the div hidden. Made sure that this div is before the actual password input. This worked for us and it didn't gave any Save Password option

Plunk - http://plnkr.co/edit/xmBR31NQMUgUhYHBiZSg?p=preview

HTML:

<form method="post" action="yoururl">
      <div class="hidden">
        <input type="password"/>
      </div>
      <input type="text" name="username" placeholder="username"/>
      <input type="password" name="password" placeholder="password"/>
    </form>

CSS:

.hidden {display:none;}

Illation

One advantage of this way vs the ones who use hidden inputs is that this way a password is never stored in a plaintext field – Arin

@Illation This didn't work for me in Chrome 47.0.2526.111 ... the trick to make it work was to add another field text in the hidden div. The browser ask to save the password BUT its says "Are you sure to save this crendetials?" and then it show a blank username and a blank password. This has worked. – Indigestible

whyAto8's solution together with @David Bélanger's comment worked for me (none of the other solutions did). I should also mention that I added the two blank hidden fields BEFORE the ones actually used for data entry, and the duplicated (hidden) fields had the same respective names. This way Chrome (48.0.2564.103) did not even ask whether any password should be saved. – Nasion

No combination of this is working on Chrome 48.0.2564.116. Even combined with DavidBelanger's comment, the Chrome popup asking you to save the password still caches the password if you click ok – Reserve

Great answer .. Just may you please tell me why did you say "Made sure that this div is before the actual password input"? I put that div after that actual password input and still it works.. So why did you mention that? – Audsley

Hey, am sorry, I wouldn't be sure about the purpose, as I moved to another project. What I think it was, that we wanted to have this hidden but also apply all the interactions which user was doing with actual input shown on UI. So, as soon as user does something on input, which is visible, we copied the interaction to the hidden one and passed on the data. – Illation

Works for Google Chrome 53, iOS10 Safari, and IE11. This was a serious pain in the butt to track down. Definite up-vote!! – Must

No, it doesn't for Chrome 94.0.4606.71 – Scup

Answer 5

You can prevent the browser from matching the forms up by randomizing the name used for the password field on each show. Then the browser sees a password for the same the url, but can't be sure it's the same password. Maybe it's controlling something else.

Update: note that this should be in addition to using autocomplete or other tactics, not a replacement for them, for the reasons indicated by others.

Also note that this will only prevent the browser from auto-completing the password. It won't prevent it from storing the password in whatever level of arbitrary security the browser chooses to use.

Polymer

[@Joel](#32409) that might prevent the form from being auto-populated but would that prevent the browser from then asking to save the password for this supposed new form? – Goodell

I don't believe this will work now. In FF 13, I have a form with several password fields, all with different names. FF, once it saves a password for that page, sticks the saved password into ALL of the password fields. It does not care what the name of the fields are (I have "new_password" and "old_password" for example, and the saved password gets dumped into both of them). In this particular form I don't have a username to save the password against - just two password fields, in case that makes a difference. – Byebye

Nods @Jason, giving the password field a new UUID for a name each time did nothing to defeat the browser's attempts to fill it in. – Zarate

Answer 6

The cleanest way is to use autocomplete="off" tag attribute but Firefox does not properly obey it when you switch fields with Tab.

The only way you could stop this is to add a fake hidden password field which tricks the browser to populate the password there.

<input type="text" id="username" name="username"/>
<input type="password" id="prevent_autofill" autocomplete="off" style="display:none" tabindex="-1" />
<input type="password" id="password" autocomplete="off" name="password"/>

It is an ugly hack, because you change the browser behavior, which should be considered bad practice. Use it only if you really need it.

Note: this will effectively stop password autofill, because FF will "save" the value of #prevent_autofill (which is empty) and will try to populate any saved passwords there, as it always uses the first type="password" input it finds in DOM after the respective "username" input.

Implement

What's the point in preventing the browser from filling in the password but allowing it to store it? It only tricks the user into thinking that their password isn't stored while they're actually vulnerable. – Rumormonger

This way it won't actually store your password, because you type into the other box, which is ignored by FF. Instead it will store an empty string. – Implement

@Rumormonger IMHO you should reconsider your downvote, because your concern is not valid – Implement

Answer 7

Use real two-factor authentication to avoid the sole dependency on passwords which might be stored in many more places than the user's browser cache.

Hypoderma

btw it's authentication not authentification – Afghan

@Jonathan Pity, i prefer authentification – Cecillececily

Another solution could be implementing a JavaScript, which forcefully closes the browser once the user is logged out of the application. This will flush the complete memory of the browser, and hence no data can be retrieved from the browser’s memory. – Meridithmeriel

Answer 8

I have tested that adding autocomplete="off" in form tag in all major browsers. In fact, Most of the peoples in US using IE8 so far.

1. IE8, IE9, IE10, Firefox, Safari are works fine.

   Browser not asking "save password". Also, previously saved username & password not populated.

2. Chrome & IE 11 not supporting the autocomplete="off" feature
3. FF supporting the autocomplete="off". but sometimes existing saved credentials are populated.

Updated on June 11, 2014

Finally, below is a cross browser solution using javascript and it is working fine in all browsers.

Need to remove "form" tag in login form. After client side validation, put that credentials in hidden form and submit it.

Also, add two methods. one for validation "validateLogin()" and another for listening enter event while click enter in textbox/password/button "checkAndSubmit()". because now login form does not have a form tag, so enter event not working here.

HTML

<form id="HiddenLoginForm" action="" method="post">
<input type="hidden" name="username" id="hidden_username" />
<input type="hidden" name="password" id="hidden_password" />
</form>

Username: <input type="text" name="username" id="username" onKeyPress="return checkAndSubmit(event);" /> 
Password: <input type="text" name="password" id="password" onKeyPress="return checkAndSubmit(event);" /> 
<input type="button" value="submit" onClick="return validateAndLogin();" onKeyPress="return checkAndSubmit(event);" /> 

Javascript

//For validation- you can modify as you like
function validateAndLogin(){
  var username = document.getElementById("username");
  var password = document.getElementById("password");

  if(username  && username.value == ''){
    alert("Please enter username!");
    return false;
  }

  if(password && password.value == ''){
    alert("Please enter password!");
    return false;
  }

  document.getElementById("hidden_username").value = username.value;
  document.getElementById("hidden_password").value = password.value;
  document.getElementById("HiddenLoginForm").submit();
}

//For enter event
function checkAndSubmit(e) {
 if (e.keyCode == 13) {
   validateAndLogin();
 }
}

Good luck!!!

Techno

Although this answer provide useful information, it does not really answer the question of how to stop browsers from saving passwords. – Lahnda

@JW Lim, I have updated the answer. Please look into it. Thanks! – Techno

@Sivakumar, Ok please include the OS and version of Safari. so that other people aware of the same. it was working in my system (windows 8, Safary 5) – Techno

@Techno Safari 8.0.3 and Mac OS 10.10 – Elidaelidad

Answer 9

Not really - the only thing you could realistically do is offer advice on the site; maybe, before their first time signing in, you could show them a form with information indicating that it is not recommended that they allow the browser to store the password.

Then the user will immediately follow the advice, write down the password on a post-it note and tape it to their monitor.

Scrubland

You have to remember this is a government site, and such things are politically charged. If someone up high says, "it must not work like this", then what is realistic is not a part of the equation. The problem may be moved to Post-It notes, but the policy on those is for a different department to handle - the problem has been moved on ;-) And I'm actually being serious. – Byebye

Answer 10

What I have been doing is a combination of autocomplete="off" and clearing password fields using a javascript / jQuery.

jQuery Example:

$(function() { 
    $('#PasswordEdit').attr("autocomplete", "off");
    setTimeout('$("#PasswordEdit").val("");', 50); 
});

By using setTimeout() you can wait for the browser to complete the field before you clear it, otherwise the browser will always autocomplete after you've clear the field.

Damnable

Answer 11

if autocomplete="off" is not working...remove the form tag and use a div tag instead, then pass the form values using jquery to the server. This worked for me.

Monahon

Answer 12

Because autocomplete="off" does not work for password fields, one must rely on javascript. Here's a simple solution based on answers found here.

Add the attribute data-password-autocomplete="off" to your password field:

<input type="password" data-password-autocomplete="off">

Include the following JS:

$(function(){
    $('[data-password-autocomplete="off"]').each(function() {
        $(this).prop('type', 'text');
        $('<input type="password"/>').hide().insertBefore(this);
        $(this).focus(function() {
            $(this).prop('type', 'password');
        });
    });     
});

This solution works for both Chrome and FF.

Jeepers

Windows Firefox 57.0.2 (64-bit) is still suggesting to save password after I implemented this. – Feast

Answer 13

This is my html code for solution. It works for Chrome-Safari-Internet Explorer. I created new font which all characters seem as "●". Then I use this font for my password text. Note: My font name is "passwordsecretregular".

<style type="text/css">
         #login_parola {
             font-family: 'passwordsecretregular' !important;
            -webkit-text-security: disc !important;
            font-size: 22px !important;
         }
    </style>


<input type="text" class="w205 has-keyboard-alpha"  name="login_parola" id="login_parola" onkeyup="checkCapsWarning(event)"  
   onfocus="checkCapsWarning(event)" onblur="removeCapsWarning()" onpaste="return false;" maxlength="32"/>

Myriam

Wait... what? You're setting the font of the <input> so that the user can't see the password... how does that prevent password saving? Also, this removes all the security protections that <input type="password"> fields have. Bad idea. – Patrolman

Answer 14

Just so people realise - the 'autocomplete' attribute works most of the time, but power users can get around it using a bookmarklet.

Having a browser save your passwords actually increases protection against keylogging, so possibly the safest option is to save passwords in the browser but protect them with a master password (at least in Firefox).

Witchcraft

"but power users can get around it" - that is applicable to most application features, web or not, and shouldn't be a reason to limit the system. People can also write their passwords on post-its and put it on their monitor, you can only do so much for security from the application perspective, and providing meaningful default behaviour (not saving it locally) is a start. – Geithner

Answer 15

I have a work around, which may help.

You could make a custom font hack. So, make a custom font, with all the characters as a dot / circle / star for example. Use this as a custom font for your website. Check how to do this in inkscape: how to make your own font

Then on your log in form use:

<form autocomplete='off'  ...>
   <input type="text" name="email" ...>
   <input type="text" name="password" class="password" autocomplete='off' ...>
   <input type=submit>
</form>

Then add your css:

@font-face {
    font-family: 'myCustomfont';
    src: url('myCustomfont.eot');
    src: url('myCustomfont?#iefix') format('embedded-opentype'),
         url('myCustomfont.woff') format('woff'),
         url('myCustomfont.ttf') format('truetype'),
         url('myCustomfont.svg#myCustomfont') format('svg');
    font-weight: normal;
    font-style: normal;

}
.password {
  font-family:'myCustomfont';
}

Pretty cross browser compatible. I have tried IE6+, FF, Safari and Chrome. Just make sure that the oet font that you convert does not get corrupted. Hope it helps?

Godred

really neat solution there is a password font here – Cis

If you use such a solution you need to take into account that users can freely copy the text entered into this look-alike password field. Copy and cut functions are disabled on real password fields. – Barogram

Answer 16

The simplest way to solve this problem is to place INPUT fields outside the FORM tag and add two hidden fields inside the FORM tag. Then in a submit event listener before the form data gets submitted to server copy values from visible input to the invisible ones.

Here's an example (you can't run it here, since the form action is not set to a real login script):

<!doctype html>
<html>
<head>
  <title>Login & Save password test</title>
  <meta charset="utf-8">
  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
</head>

  <body>
      <!-- the following fields will show on page, but are not part of the form -->
      <input class="username" type="text" placeholder="Username" />
      <input class="password" type="password" placeholder="Password" />

      <form id="loginForm" action="login.aspx" method="post">
        <!-- thw following two fields are part of the form, but are not visible -->
        <input name="username" id="username" type="hidden" />
        <input name="password" id="password" type="hidden" />
        <!-- standard submit button -->
        <button type="submit">Login</button>
      </form>

    <script>
      // attache a event listener which will get called just before the form data is sent to server
      $('form').submit(function(ev) {
        console.log('xxx');
        // read the value from the visible INPUT and save it to invisible one
        // ... so that it gets sent to the server
        $('#username').val($('.username').val());
        $('#password').val($('.password').val());
      });
    </script>

  </body>
</html>

Toile

Windows Firefox 57.0.2 (64-bit) is still suggesting to save password after I implemented this. – Feast

well, this was just a hack, which might stop working any time :) – Toile

this is the best option! just clear the password field before submit: $('.password').val('') – Amandie

Answer 17

My js (jquery) workaround is to change password input type to text on form submit. The password could become visible for a second, so I also hide the input just before that. I would rather not use this for login forms, but it is useful (together with autocomplete="off") for example inside administration part of the website.

Try putting this inside a console (with jquery), before you submit the form.

$('form').submit(function(event) {
    $(this).find('input[type=password]').css('visibility', 'hidden').attr('type', 'text');
});

Tested on Chrome 44.0.2403.157 (64-bit).

Edwards

This actually works. This prevents the browser from saving the password. To prevent showing the password you could wrap the input field in a hidden div. And you can already do this if the DOM is loaded, no need to wait until you submit the form. – Sundew

Works on IE 11.0.9600.18161 ! – Carlow

That is true. Now I tried this in FF 44.0.2 and this hack doesn't work anymore... what a shame. In Chrome this still works. – Edwards

You could replace the input[type=submit] or button[type=submit] with a regular button[type=button] and do this in the onclick handler. If no [type=submit] is present in the form, it will also prevent the form from being submitted with the enter key and the save password prompt from showing up. – Megillah

Answer 18

I tested lots of solutions. Dynamic password field name, multiple password fields (invisible for fake ones), changing input type from "text" to "password", autocomplete="off", autocomplete="new-password",... but nothing solved it with recent browser.

To get rid of password remember, I finally treated the password as input field, and "blur" the text typed.

It is less "safe" than a native password field since selecting the typed text would show it as clear text, but password is not remembered. It also depends on having Javascript activated.

You will have estimate the risk of using below proposal vs password remember option from navigator.

While password remember can be managed (disbaled per site) by the user, it's fine for a personal computer, not for a "public" or shared computer.

I my case it's for a ERP running on shared computers, so I'll give it a try to my solution below.

<input style="background-color: rgb(239, 179, 196); color: black; text-shadow: none;" name="password" size="10" maxlength="30" onfocus="this.value='';this.style.color='black'; this.style.textShadow='none';" onkeypress="this.style.color='transparent'; this.style.textShadow='1px 1px 6px green';" autocomplete="off" type="text">

Metempsychosis

Answer 19

Markus raised a great point. I decided to look up the autocomplete attribute and got the following:

The only downside to using this attribute is that it is not standard (it works in IE and Mozilla browsers), and would cause XHTML validation to fail. I think this is a case where it's reasonable to break validation however. (source)

So I would have to say that although it doesn't work 100% across the board it is handled in the major browsers so its a great solution.

Goodell

i'm having this problem of validating as per the w3c standards. The thing is I want this functionality for a Mobile banking website. I've an assumption that mobile browsers are strict enough and may sometimes mess up the form if some invalid attribute is being used. What do you recommend in this case? – Sideways

I think that is an old style of thinking. Many recent mobile browsers are built off of WebKit and either support or gracefully ignore this attribute. I am not aware of how other countries, or browsers in older cell phones handle this but gracefully handling attributes / elements that are not known is fundamental to the a good browser. It "future proofs" the browser to not break as the web evolves. It may fall behind (not implementing new features) but it won't break. Hope that helps =) – Goodell

It should be rather a comment to the referred answer than an answer to the question itself. – Kailey

Answer 20

The real problem is much deeper than just adding attributes to your HTML - this is common security concern, that's why people invented hardware keys and other crazy things for security.

Imagine you have autocomplete="off" perfectly working in all browsers. Would that help with security? Of course, no. Users will write down their passwords in textbooks, on stickers attached to their monitor where every office visitor can see them, save them to text files on the desktop and so on.

Generally, web application and web developer isn't responsible in any way for end-user security. End-users can protect themselves only. Ideally, they MUST keep all passwords in their head and use password reset functionality (or contact administrator) in case they forgot it. Otherwise there always will be a risk that password can be seen and stolen somehow.

So either you have some crazy security policy with hardware keys (like, some banks offer for Internet-banking which basically employs two-factor authentication) or NO SECURITY basically. Well, this is a bit over exaggerated of course. It's important to understand what are you trying to protect against:

1. Not authorised access. Simplest login form is enough basically. There sometimes additional measures taken like random security questions, CAPTCHAs, password hardening etc.
2. Credential sniffing. HTTPS is A MUST if people access your web application from public Wi-Fi hotspots etc. Mention that even having HTTPS, your users need to change their passwords regularly.
3. Insider attack. There are two many examples of such, starting from simple stealing of your passwords from browser or those that you have written down somewhere on the desk (does not require any IT skills) and ending with session forging and intercepting local network traffic (even encrypted) and further accessing web application just like it was another end-user.

In this particular post, I can see inadequate requirements put on developer which he will never be able to resolve due to the nature of the problem - end-user security. My subjective point is that developer should basically say NO and point on requirement problem rather than wasting time on such tasks, honestly. This does not absolutely make your system more secure, it will rather lead to the cases with stickers on monitors. Unfortunately, some bosses hear only what they want to hear. However, if I was you I would try to explain where the actual problem is coming from, and that autocomplete="off" would not resolve it unless it will force users to keep all their passwords exclusively in their head! Developer on his end cannot protect users completely, users need to know how to use system and at the same time do not expose their sensitive/secure information and this goes far beyond authentication.

Plautus

Answer 21

I tried above autocomplete="off" and yet anything successful. if you are using angular js my recommendation is to go with button and the ng-click.

<button type="button" class="" ng-click="vm.login()" />

This already have a accepted answer im adding this if someone cant solve the problem with the accepted answer he can go with my mechanism.

Thanks for the question and the answers.

Strobotron

this obviously breaks pressing the enter or return key to submit a form though. – Heady

Answer 22

One way I know is to use (for instance) JavaScript to copy the value out of the password field before submitting the form.

The main problem with this is that the solution is tied to JavaScript.

Then again, if it can be tied to JavaScript you might as well hash the password on the client-side before sending a request to the server.

Bradway

Hashing on the client side is no substitute for hashing on the server side. I'm uncertain as to whether it's any help at all (if done in addition). – Wench

Allowing hashing on the client side is dangerous because it means that an attacker doesn't need to crack the password from the hash, they can just use the hash to log in. The hash becomes password-equivalent. – Wegner

I agree with Brilliand that the hash on the client is useful only if you also have a hash on the server before saving the password in your database. However, having a hash on the client side can help a certain amount of problems with men in the middle. This being said, since the code will be available (at least on public sites) to hackers, it probably isn't as useful as it may seem. – Seesaw

Answer 23

Facing the same HIPAA issue and found a relatively easy solution,

1. Create a hidden password field with the field name as an array.

   <input type="password" name="password[]" style="display:none" />
   

2. Use the same array for the actual password field.

   <input type="password" name="password[]" />
   

The browser (Chrome) may prompt you to "Save password" but regardless if the user selects save, the next time they login the password will auto-populate the hidden password field, the zero slot in the array, leaving the 1st slot blank.

I tried defining the array, such as "password[part2]" but it still remembered. I think it throws it off if it's an unindexed array because it has no choice but to drop it in the first spot.

Then you use your programming language of choice to access the array, PHP for example,

echo $_POST['password'][1];

Clemmer

With this you are hiding a security issue - the password's hash is still being stored in the browser's cache. – Satanic

Could you please clarify? The password would be sent as plain-text using POST. As far as I have read, POST requests cannot be cached. Are you saying there is an alternative to using POST to send data? Or are you saying that the password is stored in the browser, because it's not storing the password but the empty value at the beginning of the array, have you tested this method? – Clemmer

Answer 24

Since most of the autocomplete suggestions, including the accepted answer, don't work in today's web browsers (i.e. web browser password managers ignore autocomplete), a more novel solution is to swap between password and text types and make the background color match the text color when the field is a plain text field, which continues to hide the password while being a real password field when the user (or a program like KeePass) is entering a password. Browsers don't ask to save passwords that are stored in plain text fields.

The advantage of this approach is that it allows for progressive enhancement and therefore doesn't require Javascript for a field to function as a normal password field (you could also start with a plain text field instead and apply the same approach but that's not really HIPAA PHI/PII-compliant). Nor does this approach depend on hidden forms/fields which might not necessarily be sent to the server (because they are hidden) and some of those tricks also don't work either in several modern browsers.

jQuery plugin:

https://github.com/cubiclesoft/php-flexforms-modules/blob/master/password-manager/jquery.stoppasswordmanager.js

Relevant source code from the above link:

(function($) {
$.fn.StopPasswordManager = function() {
    return this.each(function() {
        var $this = $(this);

        $this.addClass('no-print');
        $this.attr('data-background-color', $this.css('background-color'));
        $this.css('background-color', $this.css('color'));
        $this.attr('type', 'text');
        $this.attr('autocomplete', 'off');

        $this.focus(function() {
            $this.attr('type', 'password');
            $this.css('background-color', $this.attr('data-background-color'));
        });

        $this.blur(function() {
            $this.css('background-color', $this.css('color'));
            $this.attr('type', 'text');
            $this[0].selectionStart = $this[0].selectionEnd;
        });

        $this.on('keydown', function(e) {
            if (e.keyCode == 13)
            {
                $this.css('background-color', $this.css('color'));
                $this.attr('type', 'text');
                $this[0].selectionStart = $this[0].selectionEnd;
            }
        });
    });
}
}(jQuery));

Demo:

https://barebonescms.com/demos/admin_pack/admin.php

Click "Add Entry" in the menu and then scroll to the bottom of the page to "Module: Stop Password Manager".

Disclaimer: While this approach works for sighted individuals, there might be issues with screen reader software. For example, a screen reader might read the user's password out loud because it sees a plain text field. There might also be other unforeseen consequences of using the above plugin. Altering built-in web browser functionality should be done sparingly with testing a wide variety of conditions and edge cases.

Kwarteng

Answer 25

<input type="text" id="mPassword" required="required" title="Valid password required" autocomplete="off" list="autocompleteOff" readonly onfocus="this.removeAttribute('readonly');" style="text-security:disc; -webkit-text-security:disc;" oncopy="return false;" onpaste="return false;"/>

Bregma

Answer 26

To someone still looking for a solution to disabling save password problems..

This code work for me on chrome, firefox and opera as of October 24, 2023

<script type="text/javascript">
   jQuery(document).ready(function($) {
     document.getElementById( "user_login" ).autocomplete = "off";
     document.getElementById( "user_pass" ).autocomplete = "off";
     document.getElementById('#createuser').attr('autocomplete', 'off');
} );
</script>

Outbid

Answer 27

Is there a way for a site to tell the browser not to offer to remember passwords?

The website tells the browser that it is a password by using <input type="password">. So if you must do this from a website perspective then you would have to change that. (Obviously I don't recommend this).

The best solution would be to have the user configure their browser so it won't remember passwords.

Goodell

How is it obvious that you do not recommend changing a input type field? An elaboration of security issues would be helpful. – Indetermination

@karl: because having to type the password in the open allows "shoulder surfing", the process of gleaning a password by looking at the screen whil it is being typed. – Hypoderma

Not just human shoulder surfing, but spyware or viruses can watch your screen and see what has been typed in plaintext fields. – Indetermination

@karl: If you've got spyware/virus on your computer then no amount of asterisk protection is going to save you. It's no more difficult for an installed app to intercept what's being typed into a 'password' field than it is to do the same for a plain-text field. – Nalepka

Also, if the browser sees a regular text input instead of a password input, it's likely to stash the password in the form autocomplete database instead of the password database ... and then suggest it or even autofill it on some unrelated website! So you're actually even worse off than when you started. – Filipe

"So if you must do this from a website perspective then you would have to change that" - but how??? – Greenhead

Answer 28

If you do not want to trust the autocomplete flag, you can make sure that the user types in the box using the onchange event. The code below is a simple HTML form. The hidden form element password_edited starts out set to 0. When the value of password is changed, the JavaScript at the top (pw_edited function) changes the value to 1. When the button is pressed, it checks the valueenter code here before submitting the form. That way, even if the browser ignores you and autocompletes the field, the user cannot pass the login page without typing in the password field. Also, make sure to blank the password field when focus is set. Otherwise, you can add a character at the end, then go back and remove it to trick the system. I recommend adding the autocomplete="off" to password in addition, but this example shows how the backup code works.

<html>
  <head>
    <script>
      function pw_edited() {
        document.this_form.password_edited.value = 1;
      }
      function pw_blank() {
        document.this_form.password.value = "";
      }
      function submitf() {
        if(document.this_form.password_edited.value < 1) {
          alert("Please Enter Your Password!");
        }
        else {
         document.this_form.submit();
        }
      }
    </script>
  </head>
  <body>
    <form name="this_form" method="post" action="../../cgi-bin/yourscript.cgi?login">
      <div style="padding-left:25px;">
        <p>
          <label>User:</label>
          <input name="user_name" type="text" class="input" value="" size="30" maxlength="60">
        </p>
        <p>
          <label>Password:</label>
          <input name="password" type="password" class="input" size="20" value="" maxlength="50" onfocus="pw_blank();" onchange="pw_edited();">
        </p>
        <p>
          <span id="error_msg"></span>
        </p>
        <p>
          <input type="hidden" name="password_edited" value="0">
          <input name="submitform" type="button" class="button" value="Login" onclick="return submitf();">
        </p>
      </div>
    </form>
  </body>
</html>

Digit

Answer 29

autocomplete="off" does not work for disabling the password manager in Firefox 31 and most likely not in some earlier versions, too.

Checkout the discussion at mozilla about this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

We wanted to use a second password field to enter a one-time password generated by a token. Now we are using a text input instead of a password input. :-(

Merilyn

Answer 30

I was given a similar task to disable the auto-filling up of login name and passwords by browser, after lot of trial and errors i found the below solution to be optimal. Just add the below controls before your original controls.

<input type="text" style="display:none">
<input type="text" name="OriginalLoginTextBox">

<input type="password" style="display:none">
<input type="text" name="OriginalPasswordTextBox">

This is working fine for IE11 and Chrome 44.0.2403.107

Snavely

Answer 31

autocomplete="off" works for most modern browsers, but another method I used that worked successfully with Epiphany (a WebKit-powered browser for GNOME) is to store a randomly generated prefix in session state (or a hidden field, I happened to have a suitable variable in session state already), and use this to alter the name of the fields. Epiphany still wants to save the password, but when going back to the form it won't populate the fields.

Halvaard

That's even worse than storing them the usual way, since now the user doesn't see that the password was saved while not preventing an attacker from extracting the password from the store. – Rumormonger

Answer 32

I haven't had any issues using this method:

Use autocomplete="off", add a hidden password field and then another non-hidden one. The browser tries to auto complete the hidden one if it doesn't respect autocomplete="off"

Sunburn

Answer 33

Another solution is to make the POST using an hidden form where all the input are of type hidden. The visible form will use input of type "password". The latter form will never be submitted and so the browser can't intercept at all the operation of login.

Jalousie

Answer 34

Since Internet Explorer 11 no longer supports autocomplete="off" for input type="password" fields (hopefully no other browsers will follow their lead), 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.

Update: As mentioned in this comment by Gregory, Firefox will be following IE11's lead and ignore autocomplete="off" for password fields.

Lahnda

If you dont specify the username and there are multiple accounts stored in the borwser, firefox will show a prompt asking the user to pick the username :( – Hanghangar

the most simplest way to overcome this is adding an fake password field at the very beginning of the form with no name. like <input type="password" style="display:none;"/> the broswer only fill the first field. our form will work as expected. – Missy

Answer 35

i think by putting autocomplete="off" does not help at all

i have alternative solution,

<input type="text" name="preventAutoPass" id="preventAutoPass" style="display:none" />

add this before your password input.

eg:<input type="text" name="txtUserName" id="txtUserName" /> <input type="text" name="preventAutoPass" id="preventAutoPass" style="display:none" /> <input type="password" name="txtPass" id="txtPass" autocomplete="off" />

this does not prevent browser ask and save the password. but it prevent the password to be filled in.

cheer

Repletion

Answer 36

IMHO,
The best way is to randomize the name of the input field that has type=password. Use a prefix of "pwd" and then a random number. Create the field dynamically and present the form to the user.

Your log-in form will look like...

<form>
   <input type=password id=pwd67584 ...>
   <input type=text id=username ...>
   <input type=submit>
</form>

Then, on the server side, when you analyze the form posted by the client, catch the field with a name that starts with "pwd" and use it as 'password'.

Drinking

Note that won't prevent the user from Saving the password, which is the main problem here. If we can avoid the saving, then we're good. Because avoiding the pre-fill in itself is not really useful, the password was saved somewhere. Actually, in your case the user could save it each time and litter their browser of their top-secret password... – Seesaw

Chrome makes an aggressive attempt at remembering and auto-filling username+password fields - even if they've been renamed. Joy :) – Elda