1680534 - Re-mask passwords in about:logins after primary password timeout

Status: VERIFIED FIXED

(Firefox :: about:logins, enhancement, P3)

Description

[Marcos Dione]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Opened the Password Manager with the primary Password.

Actual results:

The manager opened, but never closed again.

Expected results:

It would be nice it it would close from time to time, and or close when the lid closes/the screen is turned off (for mobile versions) or be able to close it via a signal or CLI call.

Comment 1

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Sam Foster [:sfoster] (he/him)]

I'm re-titling this as we would not just close a user's tab for them, but re-masking any unmasked password fields when the primary password timeout is exceeded does seem reasonable.

Comment 3

[Marcos Dione]

I didn't mean to close the tab, just the password store, like many other password managers do. I've been used to it since the early days of kwallet in kde-3.2, year 2004.

Comment 4

[Tim Giles [:tgiles]]

To help Mozilla out with this bug, here's the steps:

1. Comment here on the bug that you want to volunteer to help. I (or someone else) will assign it to you.
2. Download and build the Firefox source code
   • If you have any problems, please ask on Element/Matrix in the introduction channel. They're there to help you get started.
   • You can also read the Developer Guide, which has answers to most development questions:
3. Start working on this bug.
   • The majority of the work will probably live in AboutLoginsParent.jsm as this is where we handle primary password requests and set the _authExpirationTime to ensure the primary password is required after 5 minutes, as well as AboutLoginsChild.
   • You will most likely need to add a variable similar to _authExpirationTime to handle a timeout function to lock the password management interface
     • The timeout function will need to send a message to AboutLoginsChild through this.sendAsyncMessage("AboutLogins:LockPasswordUI") or some other applicable message name ("AboutLogins:LockManagementUI" or something)
     • When AboutLoginsChild receives the message, you will need to send a custom event to the window where the custom event is new CustomEvent("AboutLoginsClearSelection")
       • This will clear the change login UI to the default state and since the _authExpirationTime has expired, when a user tries to view an existing login they will be prompted for their primary password (or OS reauth if enabled)
   • The timeout function will need to be cleared and re-set any time the user is authorized
   • If you have any problems with this bug, please comment on this bug and set the needinfo flag for me. Also, you can find me and my teammates on the #lockwise-desktop channel on Element/Matrix most hours of most days.
4. Build your change with mach build and test your change with mach test browser/components/aboutlogins/. Also check your changes for adherence to our style guidelines by using mach lint
5. Submit the patch (including an automated test, if applicable) for review. Mark me as a reviewer so I'll get an email to come look at your code.
   • How to Submit a Patch
6. After a series of reviews and changes to your patch, I'll mark it for checkin or push it to autoland. Your code will soon be shipping to Firefox users worldwide!

Comment 5

[bfmags]

Hi Tim, thank you for the amazing scoping 🙇‍♂️ I'm keen on having a look at this issue. Cheers

Comment 6

[Harsh Gupta]

Hey Tim! I was looking to work on this issue. Could you this assign this to me ? @tgiles

Comment 7

[bfmags]

Hi Harsh, I was thinking of picking this up, but only had a brief look at it, so you can go ahead and take it. Are you working on it now?

Comment 8

[Harsh Gupta]

Hey @bfmags! Thanks!
Yeah, I've kinda had a look at some of the files possibly needed to be modified here, and possibly enough to starting code for those changes.

Comment 9

[bfmags]

brilliant, I'll keep an eye on your patch! Thanks

Comment 10

[Harsh Gupta]

Attachment: Bug 1680534 - Remask Passwords in AboutLogins after a Primary Password Timeout of 5 Minutes r=tgiles

Comment 11

[Tim Giles [:tgiles]]

Hey Harsh, are you still able to work on this ticket? I haven't seen any activity for a week and wanted to make sure things were moving with this patch.

Comment 12

[Harsh Gupta]

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

Hey Harsh, are you still able to work on this ticket? I haven't seen any activity for a week and wanted to make sure things were moving with this patch.

Hey! I'm sorry, I was a little busy with some university work. I can start work again on this tommorow if that's okay. Thanks

Comment 13

[Tim Giles [:tgiles]]

No worries, just wanted to make sure you were still planning on working on the issue! Looking forward to an updated patch, please reach out if you have questions!

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3e45abe3876
Remask Passwords in AboutLogins after a Primary Password Timeout of 5 Minutes r=tgiles

Comment 15

[Natalia Csoregi [:nataliaCs]]

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

Comment 16

[Simona Rosu [:srosu], Ecosystem QA]

I have verified this issue using the latest Firefox Nightly 86.0a1 (Build ID: 20210118214232) on Windows 10 x64, Ubuntu 20.04 and MacOS 10.15.6.

• A shown password is automatically hidden after the OS password/primary password is timeout.

While verifying this I have encountered two behaviors when the password is not re-masked:

1. The password is not masked in Edit mode after OS password/primary password is timeout.
2. While you are in the locked screen, the time is not counted, and the password is still shown after the screen is unlocked until the timeout is reached.

Do you want to log these 2 behaviors? Or are these expected?

Comment 17

[Tim Giles [:tgiles]]

(In reply to Simona Rosu [:srosu], Ecosystem QA from comment #16)

While verifying this I have encountered two behaviors when the password is not re-masked:

1. The password is not masked in Edit mode after OS password/primary password is timeout.

This is expected behavior.

2. While you are in the locked screen, the time is not counted, and the password is still shown after the screen is unlocked until the timeout is reached.

I'm not sure what you mean by the "locked screen"? I modified my local Nightly to have the timeout fire after five seconds and it always seems to remask after five seconds even if I immediately lock my computer after viewing the password.

Comment 18

[Simona Rosu [:srosu], Ecosystem QA]

I referred to the following scenario:

1. I changed the Lock Screen timeout in 2 minutes.
2. I navigated to the “about:logins” page and clicked on the “Show” button from any saved login.
3. I waited for the screen to enter in locked mode and then waited for another ~10 minutes.
4. I unlocked the screen and observed that the password is still shown. But, after waiting 3 more minutes the password is re-masked. Somehow, I think that the time is not counted while the computer is in the Lock Screen.

Comment 19

[Tim Giles [:tgiles]]

I still can't reproduce. Just tested with Nightly with build ID: 20210119091250

1. Enable primary password
2. View password of saved login
3. Enter primary password
4. Lock machine (I'm on Windows, so Win + L)
5. Set timer for 5 minutes and one second, since the authorization timeout is 5 minutes
6. Unlock machine
7. Password is remasked

Comment 20

[Simona Rosu [:srosu], Ecosystem QA]

Hi Tim, I tried to reproduce the issue described above on Windows 10 x64, Ubuntu 20.04 and MacOS 10.15.6, but it seems to be reproducible only on MacOS.

Comment 21

[Tim Giles [:tgiles]]

Hey Simona, I'm still unable to reproduce. Just tested on MacOS 11.1 on Fx 87.0 with build ID: 20210127093943 using my steps in Comment #19. Not sure what to try next...

Comment 22

[Simona Rosu [:srosu], Ecosystem QA]

I have updated the macOS version to 11.1 and I still reproduce the issue using the steps from comment 18 and comment 19. I have tested using the latest Nightly 87.0a1 (Build ID: 20210127213646).

• For comment 18 here ar the exact steps that I have noticed:

1. I changed the Lock Screen timeout in 2 minutes.
2. At 2:27 pm I clicked on the “Show” button from any saved login and entered the OS password.
3. At 2:29 the screen naturally entered in locked mode.
4. I waited for another ~6 minutes.
5. At 2:35 I unlocked the screen and observed that the password is still shown.
6. Only at 2:37 the password was re-masked.

• For comment 19 here ar the exact steps that I have noticed:

1. I changed the Lock Screen timeout in 5 minutes.
2. At 2:40 pm I clicked on the “Show” button from any saved login and entered the OS password.
3. Also, at 2:40 locked the screen manually.
4. I waited for another ~8 minutes.
5. At 2:48 I unlocked the screen and observed that the password is still shown.
6. Only at 2:51 the password was re-masked.

Comment 23

[Tim Giles [:tgiles]]

I was able to reproduce. The issue does not appear when manually locking the user account, only when the computer goes into a screen saver mode. This sounds like a related but separate bug from this.

I'll go ahead and file one. Thanks for the STR :srosu!

Comment 25

[Marcos Dione]

Re-mask passwords in about:logins after primary password timeout

This is now what I reported earlier. My feature was to ask for the Primary Password more often (timeout configurable), independently of whether about:logins is open or not.

Having said that, this feature is in the right direction. My question would now be: should I change the Title of this bug, or should I open a new one?

Meanwhile, i downloaded the beta a couple of days ago, gave it a try. Passwords were remasked after a while in about:logins. Good job!

Comment 26

[Tim Giles [:tgiles]]

Marcos, please open up a new ticket for any follow up issues. Thanks!

Comment 27

[Marcos Dione]

This is now what I reported earlier

I meant to say, "this is not what I wanted to report initially".

Comment 28

[Marcos Dione]

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

Marcos, please open up a new ticket for any follow up issues. Thanks!

I just did. https://bugzilla.mozilla.org/show_bug.cgi?id=1692143 Thanks!