Are you using an extension like LastPass or 1Password, or is this just browser autocomplete?

This is just OSX Chrome autocomplete. On Chrome settings I have auto-fill for forms disabled but "Offer to save passwords I enter on the web" enabled.

Chrome has started ignoring autocomplete=off in 34, and it autocompletes into the first password field with a text field above it that it can find. The only workaround is to insert a dummy text and password field above the real ones, and make them display:none. Chrome will fill them with your username and password and leave the real ones alone.

Here's the chromium issue: https://code.google.com/p/chromium/issues/detail?id=352347

Firefox and IE11 have implemented their password handlers to ignore the attribute as well. Unfortunately, if you have your browser remember your password on a same domain, it doesn't seem as though you'll be able to get away from this.

If the form or the password field has autocomplete=off, Firefox won't autofill the fields on page load, but will show autocomplete suggestions, and will autofill the password field once you select the suggested remembered username (or enter it manually) in the text field above the password field.
Without autocomplete=off, it autofills on page load, like Chrome.

I was unable to get IE11 to autofill the fields.

@nkovacs
I can also confirm that IE11 doesn't autopopulate, but FF30 does (both windows and debian). Chrome 35 on windows doesn't autofill, Chrome 35 on debian does.

There should be a way to disable automatic auto-completion of the username for this box. It leads to much confusion when a removed username is shown again when the LDAP settings page is reopened. This leads to the impression that the username deletion was not applied

According to each browser's bug reports / docs, this cannot be controlled by HTML attributes and is browser behavior.

◀ Merged tasks: T5753.

@swisspol: Consensus seems to be that modern browsers have stopped respecting any instructions to disable password autocomplete.

I imagine we'll end up shoving hidden password fields in forms to work around this, but yeuch.

Offhand, we don't really want browsers silently auto-completing user passwords and submitting password plaintext from arbitrary forms, which adds another layer of mess here.

In T5579#17, @epriestley wrote:

@swisspol: Consensus seems to be that modern browsers have stopped respecting any instructions to disable password autocomplete.

I imagine we'll end up shoving hidden password fields in forms to work around this, but yeuch.

Firefox still respects it, in that it won't autofill into those fields, and hopefully chrome will do that too, probably after people start putting invisible password fields into their forms, and the chrome devs realize how much they've broken the web.
Chrome also won't offer to remember the password in the invisible field if it's empty or if it was autofilled by chrome, so I don't think that will be a problem, though it might cause unwanted behavior in other browsers and password managers.

◀ Merged tasks: T5157.

It seems like the way forward here is:

• Build a new PHUISneakyPasswordTrickView which renders a form with a fake login field (do we need this?) and a fake password field. It should:
  • render a full form tag, not just inputs (so if credentials autofill, they don't go over the wire when the real form is submitted);
  • be hidden (so users can't see it);
  • be marked non-aural (so users can't hear it);
  • have a bogus action, like posting to localhost (so if it's somehow submitted accidentally no credentials go over the wire).
• Add convenience methods like setPreventPasswordAutocomplete() on AphrontFormView and AphrontDialogView. These cause the new PHUISneakyPasswordTrickView to be embedded above the form or dialog, outside of the containing <form /> tag.
• Call these methods on all forms/dialogs which include password controls, except the actual username/LDAP login forms.
• Verify this actually prevents the bad browser behaviors. If possible, verify this fixes 1Password too.

A separate form won't work. Chrome autofills into both forms.

Edit: however, Chrome 36.0.1985.125 does not autofill if it sees too many password fields, and you could omit the name attributes of the fake fields to prevent them from being submitted.

I think it creates an unacceptable security risk to put a possibly auto-filling hidden input in the same form. Even though the browser may not submit it, it could be picked up by Javascript serialization (and probably is). And even if we fix all our serialization today, this behavior is extremely surprising and could easily be forgotten about. I don't want to create even a small risk of submitting user credentials unknowingly over the wire to correct this UI annoyance.

I'd recommend you raise this issue to your browser / password manager vendors. If they provide a reasonable way to disable this behavior (where "reasonable" means it does not involve creating any risk of submitting credentials over the wire without user knowledge) we're happy to enable it, but it looks like no such behavior exists, and vendors are going out of their way to prevent sites from disabling these behaviors (i.e., intentionally making autofill more aggressive).

I sympathize with browser vendors and think they're generally in the right here in spirit (that is, I think most sites disabling credential management are in the wrong, and I've resisted a number of HackerOne reports that we're "vulnerable" because we don't disable credential management for site login).

I also sympathize with users, and recognize this behavior sucks. However, it's not even slightly our fault, and there's no reasonable way to fix the behavior (at least, not one we can identify), and I don't want to get into an arms race with browser vendors when a mistake on our side could affect real security in a material way.

I'll add autocomplete="off" to these fields, since it sounds like at least Firefox sort of respects that, and hopefully newer versions of Chrome, etc., will choose less aggressive behaviors in response to this hint.

I posted a comment about this on the Chromium issue: https://code.google.com/p/chromium/issues/detail?id=352347#c60