1105331 - Get Okta to stop disabling password auto-fill

Status: RESOLVED FIXED

(Infrastructure & Operations :: SSO: Issues, task)

Description

[Simon Sapin (:SimonSapin)]

On https://mozilla.okta.com/ , the Mozilla LDAP Password field is not auto-filled even if Firefox’s password manager has a password stored for it. Okta uses autocomplete="off", presumably as a "security" measure.

Bug 956906 changes Firefox’s behavior to save passwords despite autocomplete="off". As discussed there, such "security" measures are wrong and not in the best interest of the user.

However the password is still not auto-filled here. I’m only speculating, but Okta seems to be playing some tricks to work around Firefox’s behavior:

  <input name="hidden-password" autocomplete="off" style="display:none;" type="password">
  <input name="password" autocomplete="off" type="password">

Bug 1101026 is about changing the browser again to defeat those tricks. But rather than enter an arm’s race with Okta, can we ask them to not do that? Since we use them for @mozilla.com login, presumably Mozilla Corporation has some kind of commercial relationship with them.

Comment 1

[Mark Banner (:standard8)]

Raising priority as this is obviously a productivity drain for those that hit it (relative to pre SSO days).

Comment 2

[Justin Dow [:jabba]]

I've filed Okta issue 27685 (probably not publicly accessible) and escalated to our account manager. Hopefully we seem some useful response.

Comment 3

[John Ford [:jhford] CET/CEST Berlin Time]

Has there been any action from Okta?  I still need to type my long and difficult to type password each time I sign in.

Comment 4

[Justin Dow [:jabba]]

Response from Okta:

    Justin,

    Hope you had a great holiday. There is currently some debate among users whether to allow (ease of use) or block (security) auto-fill. The best way for you to voice your opinion is to put in a feature request through our Support Portal under the Forums - Feature Request section. This also will allow other users to vote on this request. Here is the link.

    https://support.okta.com/forums/344921-Feature-Requests

    Please let me know if you have any questions. This ticket will be placed on 24 hour hold but will only be closed if we don't hear back from you. After that, it can be re-opened at any time by responding to this email.

    Thank you & Happy New Year!

    Best Regards,

My response:

    I understand having secure defaults, but this site is specifically breaking intended behavior of a web browser. It goes beyond standard autocomplete="off" and goes an extra step to override an end-user's wish to override this default. I've filed https://okta.zendesk.com/entries/105553256-stop-disabling-password-auto-fill but I don't think this is a feature that should be voted on by the community. It is a bug that is specifically breaking an end-user's web experience by overriding normal browser behavior, resulting in a poor user experience. Obviously this is an important issue for us, due to the nature of our business as a leading web browser provider and advocate for user experience on the web. It reflects poorly on us when a product we use and pay for directly breaks our own product on purpose.

Response from Okta:

    Justin,

    Thank you for the quick response. What is the best number to call you on to discuss further? We've got tickets open on both sides of the debate - to enable or disable auto-fill: ease of use versus security.

My response:

    I think in the case where you are torn by differing opinions, it might be best to just make it a configurable preference. Technically this is a browser’s job to enforce and not a web application’s. You could simply make everyone happy by making an org-specific setting that enables or disables the functionality, but the correct path is to let the web browser do its job. Web browser’s already have user preferences to add or remove the auto-fill functionality.

    Justin

Comment 5

[Simon Sapin (:SimonSapin)]

> There is currently some debate among users whether to allow (ease of use) or block (security) auto-fill.

Assuming that disabling auto-fill improves security is, to put it nicely, misguided, and actually leads to worse security.

https://bugzilla.mozilla.org/show_bug.cgi?id=956906
> This behavior is a concession to sites that think password managers are harmful
> and thus want to prevent them from being effective. In aggregate, I think those
> sites are generally wrong, and shouldn't have that much control over our behavior.

https://blog.0xbadc0de.be/archives/124
> By setting this parameter, you opt out of password management and force the user
> free to use less optimal management techniques like weak passwords or password sharing.

Comment 6

[Justin Dolske [:Dolske]]

It's been a week since the last update, and this continues to be a major annoyance to Mozilla employees. How can we get this escalated to get some definitive action so it doesn't drag on further?

Comment 7

[Justin Dow [:jabba]]

On Monday I got this response from them:

Justin,

Thank you for sending the additional comments from your user Simon Sappin. I have added them to the internal escalation.


Not sure what else we can do, they seem to have customers arguing both sides of the issue.

Comment 8

[(no longer active)]

We pay them, right?  We should be able to get them to add a conditional like |if (mozilla) { doTheRightThing(); } else { doWhatEveryBodyElseWants(); }|.

Comment 9

[Justin Dow [:jabba]]

I have asked if they are willing to override their faulty behavior just for our organization.

Comment 10

[(not currently active) Ted Mielczarek]

Just curious, was this behavior noticed during the trial period before we rolled Okta out to the whole organization? This seems like it should have been a big red flag.

Comment 11

[David Torre [:dtorre]]

As Justin noted above, we've opened a ticket with Okta asking if we can customize the HTML of our portal located at https://mozilla.okta.com. 

Assuming Okta is amenable to customizations, what exactly should we be asking for? We need specific code examples or a web developer contact within Mozilla we can go to for advice when Okta asks for specifics.

Comment 12

[(no longer active)]

I think all they need to do is to change this:

<input name="hidden-password" id="hidden-pass-signin" autocomplete="off" style="display:none;" type="password">

to:

<input name="hidden-password" id="hidden-pass-signin" style="display:none;" type="password">

Comment 13

[(no longer active)]

And also this:

<input name="password" id="pass-signin" autocomplete="off" tabindex="2" type="password">

to:

<input name="password" id="pass-signin" tabindex="2" type="password">

Basically they should remove the occurrences of autocomplete="off".

Comment 14

[Justin Dow [:jabba]]

I have followed up with the Okta support case asking them to do this for our organization.

Comment 15

[Justin Dolske [:Dolske]]

(In reply to :Ehsan Akhgari [Away: 1/29-2/20] (not reading bugmail, needinfo? me!) from comment #12)
> I think all they need to do is to change this:
> 
> <input name="hidden-password" id="hidden-pass-signin" autocomplete="off"
> style="display:none;" type="password">
> 
> to:
> 
> <input name="hidden-password" id="hidden-pass-signin" style="display:none;"
> type="password">

No, the problem is that they have this hidden (and presumably unused) password field in the first place. It should be removed entirely. The second, unhidden field is the one the user can actually see and type in. This is the primary problem that breaks the password manager entirely.

The autocomplete=off (which, IIRC, was set on other fields) is "just" an annoyance. If everything else was ok, it just make us not automatically fill in the password when the page loads (and instead we'll offer it in the autocomplete dropdown).

It would be nice if they fixed both, the the first is the important issue.

Comment 16

[Simon Sapin (:SimonSapin)]

> asking if we can customize the HTML of our portal located at https://mozilla.okta.com. 

It’s not just HTML, it looks like there is JavaScript involved too.


> We need specific code examples for advice when Okta asks for specifics.

According to the "Response from Okta" quoted above, they know exactly what’s going on. They are actively and deliberately working against the browser to "disable" the password manager. I believe we don’t need to explain to them which part of their own code to remove, only to convince them to do it.

Comment 17

[Daniel Veditz [:dveditz]]

fwiw the following bookmarklet is useful to fix/submit the form after the PwMgr autofills (invisibly)

javascript:document.getElementById("pass-signin").value=document.getElementById("hidden-pass-signin").value;document.getElementById("credentials").submit();void(0);

Another approach would be a GreaseMonkey script (if you use it) to do the above if it finds a non-blank hidden-pass-signin. That would save you having to click the bookmarklet.

Comment 18

[Corey Shields [:cshields]]

For what its worth, lastpass autofill works.  You can get a mozilla-sponsored license through servicenow.

Comment 19

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Justin Dow [:jabba] from comment #4)
> Response from Okta:

>     Hope you had a great holiday. There is currently some debate among users
> whether to allow (ease of use) or block (security) auto-fill.

Wait a second... That logic is totally flawed.  Firefox offers and succeeds in storing the password in the password manager.  The password manager stores the password cleartext.  This problem is only applicable to those who use password managers.  It stands to reason that a password manager user would try to save their password when offered.  The only difference between having auto fill on or off is whether Firefox inserts the password automatically or a malicious user opens the password manager and copy/pastes it into the password field.

There's no substantive security difference between having the password auto fill or not.  The real debate is whether they value convenience or a false illusion of security.  They seem to not understand how password management works in one of the biggest browsers, which is a concerning when their entire job is manage passwords through browsers.

For their assertion of heightened security to be valid, they'd need to block Firefox from ever offering to store the password, which is not what they currently do.  If I'm going to be annoyed multiple times a day, can it at least be for something that so silly?

Comment 20

[Simon Sapin (:SimonSapin)]

Yes, the "security" argument is bullshit. It would still be if they had prevented the password from being saved in the first place: forcing users to type a password regularly only pushes them to pick a weaker password.

Comment 21

[Jesse Ruderman]

Forcing users to type a password regularly also opens them up to phishing.

In addition to allowing password managers to work, I'd like them to trust cookies more and show the login page less often.

Comment 22

[Jonathan Kingston [:jkt] he/him]

Out of interest how would a site indicate that a field isn't really worth saving or perhaps a good idea to.

For example one time pin input of banks, do you really want as a user all the previous pins?

From a security perspective having a cached set of tokens wouldn't be good either as a it might help an attacker reverse engineer the token generation too.

Comment 23

[Carter Shanklin]

It's great if Mozilla employees have managed to get a private workaround for this. Really. Will there be a fix for those others among us who have been forced to use Okta? At this point I am forced to log into Okta every 24 hours and am resorting to, let's just call it an extremely non-secure workaround and leave it at that.

Also if the thread is still open with Okta, the notion that Okta subverting password auto-fill makes me more secure is, as another user eloquently phrased it, "****".

Comment 24

[Simon Sapin (:SimonSapin)]

Carter, see bug 1101026 and bug 1152422 about technical work-arounds to make Firefox save and auto-fill the password despite Okta’s attempt to "disable" that. These are resolved, it works in Firefox Nightly. I’ve been using Nigthly with a separate profile just for sites that rely on Okta.

Comment 25

[Justin Dow [:jabba]]

I did speak with Okta a few weeks ago, and they told me they were working on a solution to this that will hopefully work for both schools of thought on the issue of auto-filling passwords. No time estimate was given.

Comment 26

[:Harald Kirschner :digitarald]

The bug is soon having its 10 month anniversary. :jabba, can we nudge them again?

Comment 27

[Justin Dow [:jabba]]

I think this is currently fixed? I'm not sure if it was Okta that fixed it, or Firefox, but when I go to mozilla.okta.com now, my username and password are auto-filled.

Comment 28

[Simon Sapin (:SimonSapin)]

Auto-fill currently works for me as well, but not because we’ve managed to convince Okta (which is what this bug was about). In fact, after we’ve added a work-around in the browser with bug 1101026, Okta continues to actively work against us on this: see bug 1152422 and bug 1171114.

This bug may be moot as long as we’re ahead in this cat-and-mouse game, but I wouldn’t call it "resolved".

Comment 29

[Robert Kaiser]

Yes, let's reopen that. Firefox has worked around it but we didn't get Okta to stop disabling it, and that's what the bug is about.

Comment 30

[Fred Wenzel [:wenzel]]

I looked, and they still have two hidden password fields (designed to throw off autofill) in the DOM. Lastpass *is* tricked by them into not working.

Comment 31

[Ed Morley [:emorley]]

Due to comment 30 I have to set this as a manual site password fill, which then means the same vault entry doesn't work with Persona (login.mozilla.org). If I then add two (one for Persona, one for Okta) LP then moans about re-used passwords.

Please can someone pester them again? Do we have an internal ticket number with them that's tracking this?

Comment 32

[Justin Dow [:jabba]]

I've asked about it in our Okta case.

Comment 33

[Justin Dow [:jabba]]

This might be fixed now. Okta enabled a new feature on our account that is "Block browsers from saving Okta password" which I've set to "No". Please verify and close this, if it is working as expected.

Comment 34

[Ed Morley [:emorley]]

I can confirm this now works - thank you :-)

Between comment 31 and comment 33 I had filed a support ticket against LP - so when they tried to repro it failed, however I've now linked them to some of the other company landing pages (which can be inferred from https://www.okta.com/customers/ - some big names interestingly) so hopefully they will also work around this for the poor souls at companies who choose not to enable this feature.

Comment 35

[Joel Braddock :jbraddock]

Autofill now works again w/ LastPass as well!! Thanks Justin.