Closed Bug 1721084 Opened 3 years ago Closed 3 years ago

Firefox Lockwise repeatedly prompts for primary password

Categories

(Toolkit :: Password Manager, defect, P1)

Product:
Toolkit
Component:
Password Manager
Version:
Firefox 90
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 92+ verified
firefox91 + verified
firefox92 + verified
firefox93 + verified

People

(Reporter: ca.steve.foobar, Assigned: pbz)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [passwords:primary-password])

Attachments

(1 file, 2 obsolete files)

Bug 1721084 - Do not clear auth tokens and auth cache when purging trackers. r=johannh!
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
jcristau
: approval-mozilla-release+
RyanVM
: approval-mozilla-esr91+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

  • Leave Windows running 24x7.
  • Leave Firefox open with multiple tabs--some of them containing Google mail accounts. Others containing other random sites.
  • Go to sleep
  • Wake the monitor up the next morning and there will be a prompt from Lockwise to enter the Primary password.
  • Enter the Primary password and press Enter
  • Lockwise immediately prompts for it again
  • Enter the Primary password again and press enter
  • Lockwise accepts it and stops prompting for the rest of the day

Actual results:

Same as above

Expected results:

Once the Primary password has been entered, as long as Windows and Firefox have stayed running/logged in, the Primary password should only be prompted for when viewing passwords in Lockwise, not seemingly randomly or after a long period of no activity (like overnight).

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit

Hey Steve, thanks for filing this.

Do you have Sync enabled? If you have a Firefox Account and Sync enabled, the primary password prompt will appear when Sync occurs in the background. This is because Sync needs access to your passwords which will make the prompt appear when this task runs.

As for the primary prompt reappearing immediately after you enter your password...I'm not sure why that's happening. If you do have Sync enable, maybe it's some weird interaction between these components.

Once the Primary password has been entered, as long as Windows and Firefox have stayed running/logged in, the Primary password should only be prompted for when viewing passwords in Lockwise, not seemingly randomly or after a long period of no activity (like overnight).

This is not how the primary password behaves unfortunately. The primary password prompt will reappear if you haven't been in a situation that needs it for 15 minutes. I.e., you authenticate with your primary password and then do absolutely nothing with Firefox for 15 minutes. The next time autofill tries to happen, or autocomplete, or some other Firefox task that needs access to your logins, the prompt will appear. I've filed Bug 1713862 to help improve the expectation around primary password as this is a common issue of not knowing how primary password will behave in a certain situation.

It does seem we have a bug though with those back-to-back prompts appearing.

(In reply to Tim Giles [:tgiles] from comment #2)

Once the Primary password has been entered, as long as Windows and Firefox have stayed running/logged in, the Primary password should only be prompted for when viewing passwords in Lockwise, not seemingly randomly or after a long period of no activity (like overnight).

This is not how the primary password behaves unfortunately. The primary password prompt will reappear if you haven't been in a situation that needs it for 15 minutes. I.e., you authenticate with your primary password and then do absolutely nothing with Firefox for 15 minutes. The next time autofill tries to happen, or autocomplete, or some other Firefox task that needs access to your logins, the prompt will appear. I've filed Bug 1713862 to help improve the expectation around primary password as this is a common issue of not knowing how primary password will behave in a certain situation.

Did this change in the last year? If so, which bug #? That's not how it worked before (outside of about:logins).

It does seem we have a bug though with those back-to-back prompts appearing.

Yes, I also have seen it in the last few months on Nightly.

Yes, I have Sync configured, however this is NEW behavior as of about a week or so ago. I've had Sync running for years. As for your other question, once again, I have had Firefox open 24x7 on Windows running 24x7 with Sync running 24x7 for years and this is new behavior as of about a week ago.

I can confirm the bug with Firefox 90 on Linux (openSUSE Tumbleweed), after a period of inactivity the primary password popup appears two consecutive times.
I also have Sync enabled and up to version 89 of Firefox I always had to enter the password only once per session.

(In reply to Matthew N. [:MattN] from comment #3)

This is not how the primary password behaves unfortunately. The primary password prompt will reappear if you haven't been in a situation that needs it for 15 minutes. I.e., you authenticate with your primary password and then do absolutely nothing with Firefox for 15 minutes. The next time autofill tries to happen, or autocomplete, or some other Firefox task that needs access to your logins, the prompt will appear. I've filed Bug 1713862 to help improve the expectation around primary password as this is a common issue of not knowing how primary password will behave in a certain situation.

Did this change in the last year? If so, which bug #? That's not how it worked before (outside of about:logins).

Hmm, so it seems like I got my wires crossed in this case. I had assumed that the same _repromptTimeout that exists in about:logins was also controlling the autocomplete search/request reauth cases...but this isn't the case. If you successfully authenticate with primary password, then it looks like we rely on the crypto token to tell the password manager if we're still logged in from that last authentication.

Bug 1720693 might be related or a dupe of this bug, not sure yet.

Assignee: nobody → dlee
Severity: -- → S3
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2

I noticed interesting behavior which may help narrow this down.

This morning when I got the usual prompt to reenter my primary password, instead of doing that I left the dialog box open and went to the Passwords page (Firefox Lockwise). I entered the primary password on that page to see my passwords. Once I did this, it did not prompt me a second time for the primary password like it normally does every morning.

I have the same problem since few days (v90?), but I don't use Sync.
Sometimes the password prompt appears several times in the same day.

As indicated in the Forum, several others are encountering this issue. In my case the prompt sometimes appears every few minutes.

The prompt was not frequent at first, maybe once every few hours. It is now happening as often as every five or ten minutes, possibly because I am trying to ignore it. In any case it is a significant distraction and causes concerns that a spy app may be faking the Firefox prompt. [It just happened again after about 10 minutes.} For the record, I am in a situation where Sync is active with other machines on my local WiFi network. I see the issue on each of the machines.

Is it possible that the problem is occurring because of some action by the on-line Lockwise host?

Same issue with Nightly 92.0a1 (2021-07-28) (64-bit) on Linux and I do Sync.

Operating System: openSUSE Tumbleweed 20210727
KDE Plasma Version: 5.22.3
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.13.4-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

First: 900000 seconds = 2.5 hours. (zeroes! 15 minutes * 10); This is why it seems every few hours or so...

This does appear to be a new setting introduced around 90... (FFS Firefox version 90... goes along with the random introduction of such nifty new "features" like this ... version 90+ oh, how the origins have been scuttled along the shore of "Big Boys & Girls Now" Crag).

about:config
signon.masterPasswordReprompt.timeout_ms

...being the new setting to the wonderful new "feature" in "progress"; let's beta security assuredness for the better beta of all; randomly demonstrably unassured. Keep-safe keep-us-safes.

Sorry for butting in, but

(In reply to Tim Giles [:tgiles] from comment #2)

The primary password prompt will reappear if you haven't been in a situation that needs it for 15 minutes.

I think the user should have an option on how long before the Primary(Master) is required again.
For many websites, I don't log out. It's only with sites that have personal data (banks, shops) I log out of.
And as to sync, that could be often in some cases. For example, syncing history.

It might be hard to capture a regression window, but we wonder if this is a regression.

Keywords: regressionwindow-wanted

Over the last two weeks or so, FF has this new behavior, where it asks for the Primary Password without provocation other than having tabs open without any activity on them.

Upon returning to an idling machine, there could be several password dialog boxes open and waiting for input. Again, this is new and annoying behavior.

Of course there is no indication which tab or URL spawned the request, but why should it until I attempted to interact with it?

Been dealing with this issue for too many days now.

Attended a 1 hour 40 minute meeting on Zoom and when I came back to Firefox which had been idling there were four prompts to enter the Primary Password.

Looks like time to find a better password manager. This bug is training us to give away our Primary Password to anybody that can program a "look alike" prompt.

I consider this far more than an inconvenience.

QA Whiteboard: [qa-regression-triage]

Hi Dana,
We recently received a lot of bugs reporting since Firefox 90, Firefox prompts master password randomly during the same session.

I can also reproduce this issue on the Window platform (But I guess this is not a platform-dependent bug because some reporters are from Linux).
When this bug occurs, if I do anything cause the password manager calls NSS API to decrypt (ex, opening about:login, navigating to a site with a saved login), the prompt shows up again. So it looks like the authentication is expired somehow. if I understand correctly, when a user enters the master password, it should be valid during the entire Firefox session.

Do you know if anything changed in 90 might be related to this issue?

Flags: needinfo?(dkeeler)

I started noticing this problem after upgrading to version 90.

I leave my Windows 8.1 x64 computer running 24x7. I Leave Firefox running all day, and close it when I hit the sack.

Previously, I would get the primary password prompt once, when I start Firefox in the morning. Now, I still get that prompt, but it also appears somewhat randomly every few hours.

It's not clear whether using Firefox actively or leaving the computer for a few hours makes any difference.

I've changed the setting 'signon.masterPasswordReprompt.timeout_ms' to zero but that doesn't seem to have made any difference.

Looking at bug 1711262, there were some changes to softoken, but I don't see how those would cause this. You could try backing out those patches as a starting point, though.

Flags: needinfo?(dkeeler)

Firefox 90.0.2 on Linux asks for primary password twice in the same session. The time between asks seems to be random.

I always have a tab with a webpage that periodically reloads and has basic auth configured, in other words it prompts for user/pass. When Firefox is started, the tab is opened, because it's pinned. I'm asked for primary password as the user/pass is saved for that page within Firefox. After a random period of time I'm asked for primary again, because it seems Firefox "forgets" user/pass for that page as the ask happens exactly at the reload moment. After the second time, no more asks for primary password.

This was not happening with 89 or previous versions. There was similar issue, but it was when Firefox was still in singe digit versions, i.e. years ago.

My guess it is a regression of 90.

I'm running 90.0.2 (64-bit) for Ubuntu canonical - 1.0 on Ubuntu 20.04.2 LTS.

I use sync, and keep my browser open 24/7. Every morning the prompt is there waiting for me, and the first one is always rejected, so now I just hit escape on the first one, then wait another 15 minutes for a "fresh" dialog, which does work. But WHY since 90 does it ask me every 24 hours? This is definitely new behavior, Previously only would ask after every startup, or when accessing passwords. Once entered I would never have to do it again if the browser stayed open and connected, and this is how I expect it to work!

Now it's super annoying, and if not fixed, I will have to disable the password which is LESS security. I moved from Chrome to get away from the "nanny state" where the devs assume I'm an idiot and don't understand security. PLEASE DON'T FOLLOW GOOGLE'S LEAD, I BEG YOU!

I'm running 90.0.2 on Windows 10.
It would have been nice if signon.masterPasswordReprompt.timeout_ms had been documented.
Also, a place to set it in preferences.

(In reply to RyanHokanson from comment #13)

about:config
signon.masterPasswordReprompt.timeout_ms

...being the new setting to the wonderful new "feature" in "progress"; let's beta security assuredness for the better beta of all; randomly demonstrably unassured. Keep-safe keep-us-safes.

Okay, any insight into how this setting affects the feature if set to zero?

My preferred functionality would be to time out the log-in on whatever page may be left open, but not to ask for the PW until the next time the page is accessed.

signon.masterPasswordReprompt.timeout_ms, as I understand it, is the number of milliseconds between when you choose not to enter the master passsword and hit cancel, and being reprompted.

It is not the same thing as:

* **security.ask_for_password** (default: 0 - ask once per session, 1 - Ask every time a password is needed, 2 - ask, but don't ask me for another *security.password_lifetime* 
* **security.password_lifetime** (how long in minutes to go without asking for the master password,  default: 30)

[ Crap, I should have previewed before I committed that comment ]

signon.masterPasswordReprompt.timeout_ms, as I understand it, is the number of milliseconds between when you choose not to enter the master passsword and hit cancel, and being reprompted.

It is not the same thing as:

  • security.ask_for_password (default: 0 - ask once per session, 1 - Ask every time a password is needed, 2 - ask, but don't ask me for another security.password_lifetime
  • security.password_lifetime (how long in minutes to go without asking for the master password, default: 30)

Then once per session is not working.
Because I have it set to that, and it's asking.

(In reply to marty from comment #29)

(In reply to RyanHokanson from comment #13)

about:config
signon.masterPasswordReprompt.timeout_ms

...being the new setting to the wonderful new "feature" in "progress"; let's beta security assuredness for the better beta of all; randomly demonstrably unassured. Keep-safe keep-us-safes.

Okay, any insight into how this setting affects the feature if set to zero?

Well, so far my experience is that this only extends the re-ask annoyance to 1 day, rather than the 90000...ms = 2.5 hours...

It's an improvement. And I don't mind the daily re-ask so much; just as I don't mind the re-ask in certain heightened situations (eg. browsing passwords).

It should have been documented. It should still be documented. It should be more accessible.

(In reply to Mark Sicignano from comment #30)

signon.masterPasswordReprompt.timeout_ms, as I understand it, is the number of milliseconds between when you choose not to enter the master passsword and hit cancel, and being reprompted.

It is not the same thing as:

* **security.ask_for_password** (default: 0 - ask once per session, 1 - Ask every time a password is needed, 2 - ask, but don't ask me for another *security.password_lifetime* 
* **security.password_lifetime** (how long in minutes to go without asking for the master password,  default: 30)

XD

Yeah, the millisecond metric is silly. But, well, #kidzthezedayz

Just making my displeasure with this annoyingly big-brotherish security nanny. Please, allow us the option to turn this feature off.

Thanks!

(In reply to marty from comment #29)

(In reply to RyanHokanson from comment #13)

about:config
signon.masterPasswordReprompt.timeout_ms

...being the new setting to the wonderful new "feature" in "progress"; let's beta security assuredness for the better beta of all; randomly demonstrably unassured. Keep-safe keep-us-safes.

Okay, any insight into how this setting affects the feature if set to zero?

My preferred functionality would be to time out the log-in on whatever page may be left open, but not to ask for the PW until the next time the page is accessed.

6 hours ago I change the setting to zero. The PW entry has continued to pop up every hour or so.

(In reply to marty from comment #36)

(In reply to marty from comment #29)

(In reply to RyanHokanson from comment #13)

about:config
signon.masterPasswordReprompt.timeout_ms

...being the new setting to the wonderful new "feature" in "progress"; let's beta security assuredness for the better beta of all; randomly demonstrably unassured. Keep-safe keep-us-safes.

Okay, any insight into how this setting affects the feature if set to zero?

My preferred functionality would be to time out the log-in on whatever page may be left open, but not to ask for the PW until the next time the page is accessed.

6 hours ago I change the setting to zero. The PW entry has continued to pop up every hour or so.

Well for me it has worked as I say: now just once a day (unless I go somewhere where it's always been triggered, such as to passowrd management). I'm not sure but maybe you need to restart Firefox for the new "0" setting to be realized? I think I did; and I know that I've since restarted a few times so I can take this behemoth (v90+ ... FFS...) memory monster out while I dance the Disco Elysium or somesuch.

(In reply to RyanHokanson from comment #37)
I'm not sure but maybe you need to restart Firefox for the new "0" setting to be realized?

Many options require the browser to be restarted to take effect.

I am affected by this behavior as well after upgrading to Firefox 90 on Windows. For me, the primary password prompts appear multiple times a day, which is very annoying. The security.ask_for_password key is set to 0 in my browser and it was always. For me, this is clearly a bug which needs to be fixed.

(In reply to René Schwarz from comment #39)

I am affected by this behavior as well after upgrading to Firefox 90 on Windows. For me, the primary password prompts appear multiple times a day, which is very annoying. The security.ask_for_password key is set to 0 in my browser and it was always. For me, this is clearly a bug which needs to be fixed.

security.ask_for_password set to 2
(default: 0 - ask once per session, 1 - Ask every time a password is needed, 2 - ask, but don't ask me for another security.password_lifetime minutes)

security.password_lifetime set to 10080 (1 week's worth of minutes)
(how long in minutes to go without asking for the master password, default: 30)

Seems to be effective for me so far, as a workaround, until security.ask_for_password = 0 gets fixed.

I haven't touched any of the mentioned about:config settings.

But I think I have a new observation. So at first I enter password when I start browser. Typically (always?) a couple of new password prompts pops up some hours later (as previously reported). What I usually do is cancel the two new prompts and enter password by triggering a fresh password prompt by pressing "Synchronise now". The new observation is that I think this second time given password last "for ever"(?) At least there was no new password prompts this morning after I left my PC and browser running overnight (I could be wrong. I was up once during the night and online - but I don't remember seeing the prompt at that time either), and it is now late afternoon on second day without any new password prompts...

(In reply to Mark Sicignano from comment #40)

security.password_lifetime set to 10080 (1 week's worth of minutes)

set to the max of 2147483647 = 4085 years for me!
I actually left security.ask_for_password set to 0 and it has the same effect for me over several days so far.

Whiteboard: [passwords:primary-password]

(In reply to Brian Del Shasta from comment #42)

(In reply to Mark Sicignano from comment #40)

security.password_lifetime set to 10080 (1 week's worth of minutes)

set to the max of 2147483647 = 4085 years for me!
I actually left security.ask_for_password set to 0 and it has the same effect for me over several days so far.

My guess: security.ask_for_password set to 0 ignores security.password_lifetime. It's only when security.ask_for_password is set to 2 that the password_lifetime is used.

A quick update here for all the recent commenters. There was no intentional change of behavior to how Primary Passsword works in recent versions of Firefox - neither when it prompts or how often it prompts. So we are actively investigating these reports as a presumed regression. An engineer is assigned to this bug and we'll get a fix out as soon as one is identified.

(In reply to Sam Foster [:sfoster] (he/him) from comment #44)

A quick update here for all the recent commenters. There was no intentional change of behavior to how Primary Passsword works in recent versions of Firefox - neither when it prompts or how often it prompts. So we are actively investigating these reports as a presumed regression. An engineer is assigned to this bug and we'll get a fix out as soon as one is identified.

I could not let this go by Sam, without giving a big THANK YOU for the update and comment! It's good to know that someone is on the case.
BTW, I don't think anyone believed it was an intentional change.

Have advanced to 91.0 and issue continues. Tried changing security.ask_for_password to 2 and security.password_lifetime to 240. Still getting multiple requests for Primary Password in periods of less than an hour, especially when I am off in another application. As commented earlier, the prompts do not come up in the screen but are setting as additional instances of Firefox that need to be addressed. Bottom Line - It appears that all of these parameters are being ignored.

I appreciate that the issue is being investigated, now lets fix it.

Hi, I just want to chime in for macOS 10.14.6: I get the same behaviour running FF 90.0.2 (64-bit). Previously the primary password requests generally arrived at the start of a new browsing session. This morning I've had multiple requests with 2 windows (of 3 tabs each) open overnight, but no activity on my part. None of the pages are logins. Hope this helps, and keep up the good work!

I am experiencing the same problem on Linux / Ubuntu 21.04 (latest version updates that comes w. the OS) and macOS (Firefox 91).
The modal box prompting for my password pops up several times during the same session, without me doing anything particular. I've never used sync. I have no antiviruses.

Steps to reproduce:

  1. start Firefox with a master password enabled, configure it with the previous session restoration
  2. disable sync
  3. type your password as prompted when the session starts
  4. open some tabs that use log in information (eg. Google, GMail, GitHub, Twitter, etc)
  5. close Firefox
  6. open Firefox again (checking that all previous processes stopped before), type the master password as prompted
  7. leave the Firefox session open for a couple of hours

Observed:

  • modal dialog box prompting for the master password appears again
  • cancelling that modal box works (sites requiring the master password continue functioning)

Expected:

  • master password is prompted only once during the lifetime of a Firefox session

The behaviour <= v89 and v90 are different. The procedure described in here https://support.mozilla.org/en-US/kb/firefox-keeps-asking-me-primary-password does not help.

At first I really thought my computer was hacked.
This is a regression.

The Knowledge Base article instructs us to REMOVE the existing Primary Password and then re-establish it.

What happens to all the account/password data that has been stored? This procedure does not explain if I will lose it all and provides no back-up procedure.

Hi Paul, Dana
I used mozregression to bisect the changeset that causes this issue, which points to the patch in Bug 1705035.
We have received a lot of users reporting this issue recently, Could you help take a look at it? thanks!

Note. I can easily reproduce this bug with the following steps:

  1. Create a profile with primary password enabled
  2. Add a login (ex. facebook.com) with about:logins
  3. Restart Firefox
  4. Navigate to the site with a login saved. The primary password prompt will pop up.
  5. Enter the primary password
  6. Login should be auotfilled after step5
  7. Wait around 5-10 mins
  8. The primary password prompt will pop up again.
Flags: needinfo?(pbz)
Flags: needinfo?(dkeeler)

(In reply to Jim from comment #49)

The Knowledge Base article instructs us to REMOVE the existing Primary Password and then re-establish it.

What happens to all the account/password data that has been stored? This procedure does not explain if I will lose it all and provides no back-up procedure.

They are not affected.

As far as I'm concerned, the method introduced in Bug 1705035 is only ever called if the user actively clears site data via nsIClearDataService: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/cleardata/nsIClearDataService.idl#78

Here are the callers of this method:

  1. SiteDataManager: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/browser/modules/SiteDataManager.jsm#523
  2. GeckoViewStorageController: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/mobile/android/modules/geckoview/GeckoViewStorageController.jsm#228
  3. ForgetAboutSite: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/forgetaboutsite/ForgetAboutSite.jsm#34

It seems unlikely that this code runs given the STR.

I can reproduce with the STR. From testing with the JS debugger, it doesn't look like we ever hit this method.

Flags: needinfo?(pbz)
Flags: needinfo?(dkeeler)

Hi Paul,
By looking the mozregression result more closely, I think it actually means revision range from 337402160f80 to fb2ec3d88d50, not only the last one.
Not sure if you have already verify patches in Bug 1705028 and Bug 1705029, if not, could you help check if they are related to this bug? thank you!

Flags: needinfo?(pbz)

I have been getting this behavior on my Mac mini and Macbook Pro. I first thought it was a sign of an exploit until I started seeing other people reporting the same problem for v90.

Expected behavior is that entering the password should be sticky for at least the day, and that there should be a setting for it or at least a release note if it's going to suddenly have a short lifetime.

This looks like a regression of Bug 1705028. When the PurgeTrackerService deletes data by principal, some of the cleaners in ClearDataService will fall back to clearing all storage, since they don't know how to clear for a specific principal. This is normally desired behavior, because we would rather over-clear than leaving data behind.

This is where PurgeTrackerService calls ClearDataService: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/antitracking/PurgeTrackerService.jsm#201-216

Here are the cleaners that are most likely the problem: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/cleardata/ClearDataService.jsm#946,963

To fix this, we can pass the aIsUserRequest flag to the cleaners, and not perform any auth token clearing when the request wasn't triggered from the user, but from the PurgeTrackerService.
The alternative is to not call these two cleaners for tracker purging here: https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/toolkit/components/antitracking/PurgeTrackerService.jsm#212-213

Dimi, I can take the bug, since it's a regression of 1705028.

Assignee: dlee → pbz
Flags: needinfo?(pbz)
Regressed by: 1705028
Has Regression Range: --- → yes
See Also: → 1726043
Priority: P2 → P1

NI myself for the uplift request once this lands.

Flags: needinfo?(pbz)
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c65e56f39bc9
Do not clear auth tokens and auth cache when purging trackers. r=johannh

https://hg.mozilla.org/mozilla-central/rev/c65e56f39bc9

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox93: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

Thanks for the quick turn around, glad to see this fixed!

This issue should now be fixed on the latest Firefox Nightly 93.0a1.

Given we have many user reports about it and was quite a journey to reproduce and investigate this, if you have some spare time, please download the latest Nightly, setup your profile with a primary password and saved logins, and let us know if you experience this issue or not.
I will do this myself as well, but the more folks confirm the better and safer. There are also steps to reproduce in Comment 50 but the overnight scenario would be also great to check.

Firefox Nightly 93.0a1 can be downloaded from here: https://www.mozilla.org/ro/firefox/channel/desktop/
Marking it qe+ to have final confirmation when enough testing and bake time is done.

QA Whiteboard: [qa-regression-triage]
Flags: qe-verify+
Keywords: regressionwindow-wanted
QA Contact: timea.babos

[Tracking Requested - why for this release]: I realize that we just had a dot release. In case there is another, D122864 could be a good patch to ride along. The bug affects users who use primary password as well as basic auth. In both cases they will be periodically de-authed and prompted to auth again.

I'll request D122864 for uplift to beta and ESR once we have confirmation the issue is fixed in Nightly.
The other patches can ride the trains.

If you're not on Nightly, a temporary workaround is to disable tracker purging by setting privacy.purge_trackers.enabled to false in about:config. Make sure to enable it again once the issue is fixed.

status-firefox91: --- → affected
status-firefox92: --- → affected
status-firefox-esr78: --- → unaffected
status-firefox-esr91: --- → affected
tracking-firefox91: --- → ?

(In reply to Brian Del Shasta from comment #42)

(In reply to Mark Sicignano from comment #40)

security.password_lifetime set to 10080 (1 week's worth of minutes)

set to the max of 2147483647 = 4085 years for me!
I actually left security.ask_for_password set to 0 and it has the same effect for me over several days so far.

Based on comments here, I have security.ask_for_password set to 2 and security.password_lifetime set to 2147483647.
This has worked around the bug for a machine running Firefox 91 on the default release channel, but does not help for a different machine using the esr channel. It just updated to 91esr, which has introduced the bug, and this workaround doesn't seem to help - why?

(In reply to Paul Zühlcke [:pbz] from comment #65)

If you're not on Nightly, a temporary workaround is to disable tracker purging by setting privacy.purge_trackers.enabled to false in about:config. Make sure to enable it again once the issue is fixed.

Done.

Though I will probably certainly maybe almost possibly remember to re-enable... Please do say something in the release notes when it hits real-for-us-regular-folk rollout reality.

Thanks.

Tentatively marking this as verified-fixed on the latest Nightly 93.0a1 (2021-08-18) on Windows 10 x64.
Tested with scenario mentioned in Comment 50 (multiple times) and left the computer idle/sleep for more than 24h. The Primary Password prompt was not displayed more than once per session when the browser was launched.

If someone still encounters this issue on the latest Nightly, please do let us know. Otherwise, follow the workaround provided by Paul in Comment 65 for a Firefox version other than Nightly.

status-firefox93: fixed → verified

Comment on attachment 9236655 [details]
Bug 1721084 - Do not clear auth tokens and auth cache when purging trackers. r=johannh!

Beta/Release Uplift Approval Request

  • User impact if declined: Firefox doesn't persist the authed state correctly. When users log in via primary password or authenticate to websites via basic auth, they get prompted again in the same session every time the PurgeTrackerService runs. Depending on usage this may happen every couple hours or every day.
    A workaround is to disable the PurgeTrackerService by setting privacy.purge_trackers.enabled to false. However, this is not ideal since it disables the tracker purging.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Low risk. Minimal patch which only skips clearing the auth tokens and auth cache when the PurgeTrackerService runs.
    Fix verified manually by QA and two devs.
    The PurgeTrackerService and ClearDataService components already have good test coverage.
  • String changes made/needed: none

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Affects all users who use the primary password or basic auth to authenticate with websites.
  • User impact if declined: <See beta uplift request>
  • Fix Landed on Version: 93
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): <See beta uplift request>
  • String or UUID changes made by this patch:
Flags: needinfo?(pbz)
Attachment #9236655 - Flags: approval-mozilla-esr91?
Attachment #9236655 - Flags: approval-mozilla-beta?

Comment on attachment 9236655 [details]
Bug 1721084 - Do not clear auth tokens and auth cache when purging trackers. r=johannh!

Approved for 92.0b6 and 91.1esr.

Attachment #9236655 - Flags: approval-mozilla-esr91?
Attachment #9236655 - Flags: approval-mozilla-esr91+
Attachment #9236655 - Flags: approval-mozilla-beta?
Attachment #9236655 - Flags: approval-mozilla-beta+

I just copied the text of the workaround with the reminder to undo it and send it to every3days@followupthen.com

I don't know when the patched version will get to me, but every three days I can count on waking up to an email with the details in case Firefox does update and I forget the details.

The link above is an affiliate link. I've got 4 credits left so if anybody signs up for the service, I'll get a free month. ;-) It helps me with zero-inbox and other things.

(In reply to RyanHokanson from comment #67)

Though I will probably certainly maybe almost possibly remember to re-enable... Please do say something in the release notes when it hits real-for-us-regular-folk rollout reality.

Thanks.

(In reply to Mark Sicignano from comment #74)

I don't know when the patched version will get to me

Firefox 92 is due to ship on September 7. This fix may also ride out earlier than that in a 91 bugfix release should the opportunity arise, but as of now there are no plans for one.

Apologies for the comment edit, but affiliate links aren't a thing we do here.

(In reply to Mike Hoye [:mhoye] from comment #76)

Apologies for the comment edit, but affiliate links aren't a thing we do here.

No apologies necessary. I wasn't sure, but I respect that. It is a neat and helpful tool that has a free plan, and it works with any email client with no installation needed. Cheers.

QA Whiteboard: [qa-triaged]

Verified-fixed on the latest Firefox Beta 92.0b6 on Windows 10 x64.

status-firefox92: fixed → verified
See Also: → 1726742
See Also: → 1726743

Comment on attachment 9236655 [details]
Bug 1721084 - Do not clear auth tokens and auth cache when purging trackers. r=johannh!

Beta/Release Uplift Approval Request

Attachment #9236655 - Flags: approval-mozilla-release?

(In reply to Steve from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

  • Leave Windows running 24x7.
  • Leave Firefox open with multiple tabs--some of them containing Google mail accounts. Others containing other random sites.
  • Go to sleep
  • Wake the monitor up the next morning and there will be a prompt from Lockwise to enter the Primary password.
  • Enter the Primary password and press Enter
  • Lockwise immediately prompts for it again
  • Enter the Primary password again and press enter
  • Lockwise accepts it and stops prompting for the rest of the day

Actual results:

Same as above

Expected results:

Once the Primary password has been entered, as long as Windows and Firefox have stayed running/logged in, the Primary password should only be prompted for when viewing passwords in Lockwise, not seemingly randomly or after a long period of no activity (like overnight).

Regarding having to enter the Primary password twice I noticed that if you drag the notification window to the side there is a second window below it. When you enter the password the first time it dismisses the prompt and exposes the second window below. This makes it appear that the password was not accepted the first time and you have to enter it again. It means a second prompt was generated while a previous prompt was still open,

Regarding having to enter the Primary password twice I noticed that if you drag the notification window to the side there is a second window below it. When you enter the password the first time it dismisses the prompt and exposes the second window below. This makes it appear that the password was not accepted the first time and you have to enter it again. It means a second prompt was generated while a previous prompt was still open,

Same here on

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0

And sometimes the second loginwindow is hiding behind a ff-window - cant bring it to the front, it stucks behind the mainwindow. So I have to forcequit Firefox.

See screenshot @ https://bit.ly/3AV2BB8

Comment on attachment 9236655 [details]
Bug 1721084 - Do not clear auth tokens and auth cache when purging trackers. r=johannh!

approved for 91.0.2

Attachment #9236655 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified-fixed on the latest Release 91.0.2 on Windows 10 x64.

status-firefox91: fixed → verified
See Also: → 1727316

Comment on attachment 9236686 [details]
Bug 1721084 - ClearDataService tests to ensure that we do not fallback to clearAll for non user requests. r=johannh!

Revision D122882 was moved to bug 1727316. Setting attachment 9236686 [details] to obsolete.

Attachment #9236686 - Attachment is obsolete: true

Comment on attachment 9236685 [details]
Bug 1721084 - Avoid over-clearing data in ClearDataService if we do not have user input. r=johannh!

Revision D122881 was moved to bug 1727316. Setting attachment 9236685 [details] to obsolete.

Attachment #9236685 - Attachment is obsolete: true

Verified-fixed on the latest ESR 91.1.0esr (BuildID: 20210830184617) on Windows 10.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
status-firefox-esr91: fixed → verified
Flags: qe-verify+

(In reply to Timea Cernea [:tbabos] from comment #84)

Verified-fixed on the latest Release 91.0.2 on Windows 10 x64.

A few days testing has confirmed the fix implemented seems to have resolved the issue. Thank you to everyone involved in expediting the correction. Although apparently not classified as a Security issue, it was certainly a security procedure issue. Training application users to ignore unexpected password challenges will eventually lead to lots of hacked systems.

(In reply to Jim from comment #88)

Although apparently not classified as a Security issue, it was certainly a security procedure issue. Training application users to ignore unexpected password challenges will eventually lead to lots of hacked systems.

Also making people get used to enter password in unexpected passwords prompts at random times, ...

Good it was fixed.

What is the esr version where the fix is applied?

It will be in the 91.1esr release shipping on Tuesday, 7-Sep.

I have been dealing with this problem for a year now. It's embarrassing when Microsoft lovers laugh at the problem I deal with. It seems to me there should be a solution now rather than excuses. My solution will be to stop using sync and load it occasionally and hope this works. My password is long for security reasons and its frustrating to retype it over and over due to typos much less a bug in the browser you have relied on. I have two separate instances where users I had suggested Mozilla Firefox to absolutely refused to use Firefox when warned of the problem. One referred to it as buggy software when they can continue to use Edge without problems.

I only post this because I have reported it in the past with no resolution given.

Jim

This was resolved for me in the version cited, so it appears to have been fixed almost a year ago. Perhaps you can file a new bug to let them know there is still a problem?

(In reply to jlfliberty from comment #93)

I have been dealing with this problem for a year now. It's embarrassing when Microsoft lovers laugh at the problem I deal with. It seems to me there should be a solution now rather than excuses. My solution will be to stop using sync and load it occasionally and hope this works.

What version are you running?

I recall a workaround being posted, and then a fix followed shortly afterward. I never saw the problem again.

This issue was effectively fixed almost a year ago. Subsequently additional changes were made to have Firefox ask for this password immediately upon logging-on and the variability of prompts and opportunities for third parties to try and phish for your password were greatly diminished. BRAVO Mozilla

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

Attachment

General

Creator:
Created:
Updated:
Size: