Re-mask passwords in about:logins after primary password timeout
Categories
(Firefox :: about:logins, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | verified |
People
(Reporter: mdione, Assigned: harshgup626, Mentored)
References
(Blocks 1 open bug)
Details
(Whiteboard: [lang=js][good second bug])
Attachments
(1 file)
Bug 1680534 - Remask Passwords in AboutLogins after a Primary Password Timeout of 5 Minutes r=tgiles
48 bytes,
text/x-phabricator-request
|
Details | Review |
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•3 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•3 years ago
|
||
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.
Reporter | ||
Comment 3•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
To help Mozilla out with this bug, here's the steps:
- Comment here on the bug that you want to volunteer to help. I (or someone else) will assign it to you.
- 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:
- If you have any problems, please ask on Element/Matrix in the
- 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 asAboutLoginsChild
. - 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
throughthis.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 isnew 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)
- This will clear the change login UI to the default state and since the
- The timeout function will need to send a message to
- 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.
- The majority of the work will probably live in
- Build your change with
mach build
and test your change withmach test browser/components/aboutlogins/
. Also check your changes for adherence to our style guidelines by usingmach lint
- 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.
- 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!
Hi Tim, thank you for the amazing scoping 🙇♂️ I'm keen on having a look at this issue. Cheers
Assignee | ||
Comment 6•3 years ago
|
||
Hey Tim! I was looking to work on this issue. Could you this assign this to me ? @tgiles
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?
Assignee | ||
Comment 8•3 years ago
|
||
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.
Assignee | ||
Comment 10•3 years ago
|
||
Updated•3 years ago
|
Comment 11•3 years ago
|
||
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.
Assignee | ||
Comment 12•3 years ago
|
||
(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•3 years ago
|
||
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•3 years ago
|
||
Pushed by rmaries@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d3e45abe3876 Remask Passwords in AboutLogins after a Primary Password Timeout of 5 Minutes r=tgiles
Comment 15•3 years ago
|
||
bugherder |
Comment 16•3 years ago
|
||
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:
- The password is not masked in Edit mode after OS password/primary password is timeout.
- 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•3 years ago
|
||
(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:
- The password is not masked in Edit mode after OS password/primary password is timeout.
This is expected behavior.
- 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•3 years ago
|
||
I referred to the following scenario:
- I changed the Lock Screen timeout in 2 minutes.
- I navigated to the “about:logins” page and clicked on the “Show” button from any saved login.
- I waited for the screen to enter in locked mode and then waited for another ~10 minutes.
- 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•3 years ago
|
||
I still can't reproduce. Just tested with Nightly with build ID: 20210119091250
- Enable primary password
- View password of saved login
- Enter primary password
- Lock machine (I'm on Windows, so
Win + L
) - Set timer for 5 minutes and one second, since the authorization timeout is 5 minutes
- Unlock machine
- Password is remasked
Comment 20•3 years ago
|
||
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•3 years ago
|
||
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•3 years ago
|
||
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:
- I changed the Lock Screen timeout in 2 minutes.
- At 2:27 pm I clicked on the “Show” button from any saved login and entered the OS password.
- At 2:29 the screen naturally entered in locked mode.
- I waited for another ~6 minutes.
- At 2:35 I unlocked the screen and observed that the password is still shown.
- Only at 2:37 the password was re-masked.
- For comment 19 here ar the exact steps that I have noticed:
- I changed the Lock Screen timeout in 5 minutes.
- At 2:40 pm I clicked on the “Show” button from any saved login and entered the OS password.
- Also, at 2:40 locked the screen manually.
- I waited for another ~8 minutes.
- At 2:48 I unlocked the screen and observed that the password is still shown.
- Only at 2:51 the password was re-masked.
Comment 23•3 years ago
|
||
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!
Reporter | ||
Comment 25•3 years ago
|
||
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•3 years ago
|
||
Marcos, please open up a new ticket for any follow up issues. Thanks!
Reporter | ||
Comment 27•3 years ago
|
||
This is now what I reported earlier
I meant to say, "this is not what I wanted to report initially".
Reporter | ||
Comment 28•3 years ago
|
||
(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!
Description
•