Firefox asking to update wrong "test" password because of hidden fields

[geraldo.santos]

Hi, from some time ago firefox started to ask to update a wrong “test” password every time I login with Okta. On the password page there are 3 hidden input fields, namely okta_hidden_pass_firefox_1, okta_hidden_pass_firefox_2 and okta_hidden_pass_firefox_3 with this test value, and they are the culprits, to verify it I removed them from DOM before submitting and Firefox did not ask to update my password.

[lewis]

Been seeing this too for more than a month now.

Working well with password managers should be a core competency for Okta as a product, given its use case.

This is looks like it’s almost designed to mess with Firefox’s password manager. Why?

Please fix it.

[henrik]

It looks like this function is to blame. Why on earth would anyone want this?

return e.View.extend({
      className: "password-jammer",
      initialize: function() {
        s.bindAll(this, "template")
      },
      template: function() {
        switch (this.getBrowserType()) {
          case "safari":
            return '<input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_pass_safari_1" type="password"           autocomplete="off" />          <input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_pass_safari_2" type="password"           autocomplete="off" />';
          case "mozilla":
            return '<input style="display:none" type="password" id="okta_hidden_pass_firefox_1"           autocomplete="off" value="test" />          <input style="display:none" type="password" id="okta_hidden_pass_firefox_2"           autocomplete="off" value="test" />          <input style="display:none" type="password" id="okta_hidden_pass_firefox_3"           autocomplete="off" value="test" />';
          case "chrome":
            return '<input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_username_chrome_1"           type="text" autocomplete="off" />          <input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_pass_chrome_1"          type="password" autocomplete="off" />          <input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_username_chrome_2"           type="text" autocomplete="off" />          <input style="opacity: 0; width: 0; height: 0;" id="okta_hidden_pass_chrome_2"           type="password" autocomplete="off" />';
          default:
            return '<input id="okta_hidden_pass_1" type="password" autocomplete="off"          style="position:absolute;top:-10000px"/>          <input id="okta_hidden_pass_2" type="password" autocomplete="off"           value="test" style="display:none"/>'
        }
      },
      getBrowserType: function() {
        return t.browser.safari ? "safari" : t.browser.mozilla ? "mozilla" : t.browser.chrome ? "chrome" : "other"
      })

[andrea]

Are you all seeing this with the Okta plugin? If you’re still seeing this issue in Firefox, I’d recommend opening a support case so someone can investigate this.

[henrik]

I’m not using the Okta plugin (I guess you mean a browser plugin?). I’m seeing this in Firefox, and have submitted a support case.

[henrik]

@andrea Okta support requires that I have to be an Okta admin to send a request. It’s case 00993712 in case you are able to bypass that requirement.

[andrea]

Would you be able to get your Okta admin to join that email thread/case? Our support policy does require that we work with an Okta admin to help troubleshoot the issue, so like that Support Engineer said, you will need your admin involved in the conversation with support.

[STempus]

Also seeing this exact same problem. Firefox continually asks me to update password at each login and wants to update to password “test”.

[Murphis99]

I have the same problem with firefox.

[henrik]

Here’s the answer from Okta support:

Since you do not have the okta browser plugin installed for firefox. I would like to disable a feature in your org. This feature prevents browsers from prompting users to save passwords. It seemed weird for me in the first place that the feature is enabled, yet users are still prompted to save the password ( even with “test” as a password ) , so I have dig within our internal documentation for more insight over this functionality. Firefox prompting users to save the password as " test " with this feature enabled is actually expected , because the way this feature works, is by having heuristics where the plugin inject dummy hidden password fields into a login/change password page to trick the browser into thinking this is not a login page that requires prompting. For Firefox, it is hardcoded to be “test” by default.

Firefox prompting users to save the password as “test” is actually expected with this feature enabled. We cannot control Firefox’s prompt to save users credentials, so what this feature does, is injecting the “test” password in Firefox pop-up to save credentials. Users are still prompted in Firefox with the pop-up , but the “test” password is hardcoded by us to trick the password save somehow.
If you want users to be prompted to save their actual password within browsers, this feature in question must be disabled from the environment.

So talk to your friendly neighbourhood Okta administrator and make them ask for this “feature” to be disabled.