Closed Bug 1623861 Opened 4 months ago Closed 3 months ago

[macOS] The operating system’s authentication dialog can't be accepted if the OS doesn't have any password set


(Firefox :: about:logins, defect, P1)

76 Branch



Firefox 76
Tracking Status
firefox74 --- unaffected
firefox75 --- unaffected
firefox76 --- verified


(Reporter: cmuntean, Assigned: spohl)




(3 files, 1 obsolete file)

[Affected versions]:

  • Firefox Nightly 76.0a1 (Build ID: 20200319215651)

[Affected Platforms]:

  • Mac 10.15.3
  • Mac 10.14.6


  • Have a profile with at least one saved login.
  • No OS password is set.

[Steps to reproduce]:

  1. Open the latest Nightly Firefox browser.
  2. Navigate to the "about:logins" page and select a saved password.
  3. Click on the "Show Password" or "Copy" or "Edit" button from the login item.
  4. Observe the behavior.

[Expected result]:

  • The password is shown or copied or the edit more is opened without entering any password.

[Actual result]:

  • The operating system’s authentication dialog is displayed even if no OS password is set.


  • The issue is also reproducible if trying to check the "Use a master password" option from "about:preferences#privacy" page.
  • The OS auth is triggered and the "OK" button is clicked two times, the dialog is dismissed. However, this doesn't happen if an OS password is set. This behavior can be observed in the screen recording added bellow.
  • No errors are displayed in the browser console.
  • This issue is no longer reproducible on Windows.
  • Attached a screen recording with the issue: link.

I don't necessarily think it's a bug that the dialog appears, the problem is that the user can't accept the dialog with an empty password.

Priority: -- → P1
Summary: [macOS] The operating system’s authentication dialog is wrongly triggered even if the OS doesn't have any password set → [macOS] The operating system’s authentication dialog can't be accepted if the OS doesn't have any password set


Assignee: nobody → jaws

Hi Jared! I just tested this issue on macOS 10.14.6 with the provided build but the issue is still reproducible. I have encountered the same behavior described in comment 0. Please let me know if you need any other information.

Flags: needinfo?(cosmin.muntean) → needinfo?(jaws)

I tried doing the steps in the video of comment #0 but it says that a password is required. How were you able to create an account on 10.15.3 without a password?

Flags: needinfo?(jaws) → needinfo?(cosmin.muntean)

In order to remove the macOS password I have opened the "System Preferences" menu -> "Users & Groups" option and select the OS account. In the right part of the menu, there is a "Change Password..." button. Click the button, enter the old password and leave the "New password" and "Verify" fields empty and click the "Change Password" button. Now the account doesn't have a password and when I log in to this account, no password is required. However, on "about:logins" page the OS auth dialog is displayed and requires the OS password.

I have added in the "Notes" section at the last dot a link with a screen recording and contain also steps on how I have removed the OS password.

Flags: needinfo?(cosmin.muntean) → needinfo?(jaws)

Thank you, yes I followed the steps in your video and it is not allowed on my machine, though I now think it may be because I have FileVault enabled.

Flags: needinfo?(jaws)

I just looked at how Chrome handles this. On Chrome, if the OS account has an empty password, when I click the "Show password" button, the OS auth dialog is triggered and If I let the password field empty and click the "OK" button, the password is shown. On Firefox (latest Nightly build) if I let the password field empty and click the "OK" button the password is not shown and the OS auth dialog repapers.

Attached image OS auth dialog.png

Here is a screenshot with the OS auth dialog that is triggered when trying to reveal the password made on the latest build provided. However, the issue is still reproducible on this build.

Flags: needinfo?(cosmin.muntean)

After you hit "OK" from that dialog is there another dialog that pops up? I added a second dialog that would show what error was returned.

Flags: needinfo?(cosmin.muntean)

The same dialog pops up, it's identical with the first one. If I click "OK" on the second dialog, it's dismissed and no other dialog pops up.

Flags: needinfo?(cosmin.muntean)

Thank you Stephen!

Assignee: jaws → spohl.mozilla.bugs
Attached file accountpolicies.xml

Steps to allow/set an empty password (macOS 10.15.3):

  1. Log into the account you want to change to an empty password (they may need to be an admin?)
  2. Download this attachment as accountpolicies.xml
  3. Run the following in terminal when you're in the directory of the download
pwpolicy setaccountpolicies accountpolicies.xml
  1. Run passwd in the terminal and enter your old password aand hit enter. Hit enter twice to confirm a blank new password.
Attachment #9135088 - Attachment is obsolete: true
Pushed by
Allow for OS authentication to succeed when no passcode is set. r=mstange
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 76
See Also: → 1626247

I have retested this issue using the latest Nightly 76.0a1 build (Build ID: 20200331093527) and I have encountered the following behavior:

  • The operating system’s authentication dialog accepts the empty password only at the second attempt. To be more specific: when trying to view a password, the auth dialog is displayed and if the "OK" button is pressed without entering any password, the auth dialog disappears and reappears. If the "OK" button is clicked again, the auth dialog is dismissed and the password is correctly shown.
  • I have tested this issue on macOS 10.15.3, macOS 10.14.6 and macOS 10.13.6.
  • I have also verified on Windows 10 x64 and Ubuntu 18.04 x64 if there are no regressions.

Considering the fact that the operating system’s authentication dialog accepts the empty password (even if only at the second attempt) I'm marking this issue as VERIFIED-FIXED. For the behavior mentioned above, I have logged a separate issue in Bug 1626247.

You need to log in before you can comment on or make changes to this bug.