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 m

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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. :-(

Answer 6

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;}