Closed Bug 1194529 Opened 5 years ago Closed 7 months ago

Ask the user for their OS account password/biometrics before showing the passwords in the password manager

Categories

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

Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
Firefox 76
user-doc-firefox docs-needed
Tracking Status
relnote-firefox --- 76+
firefox76 --- fixed

People

(Reporter: rchtara, Assigned: jaws)

References

(Depends on 12 open bugs)

Details

(Whiteboard: security:passwords)

Attachments

(7 files, 2 obsolete files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
27.83 KB, image/png
Details
When the user tries to show all the passwords in the password manager, he should  be asked to enter his current windows password if he didn't setup a master password
Whiteboard: [fxprivacy] security:passwords
Whiteboard: [fxprivacy] security:passwords → [fxprivacy] [triage] security:passwords
Whiteboard: [fxprivacy] [triage] security:passwords → security:passwords
Bug 1121291 is removing the "Show passwords" button, so I think this would be a wontfix.
Or is this a duplicate of Bug 902880?
Flags: needinfo?(rchtara)
No, they are different: here we have to ask for the windows password before showing all the passwords
After Bug  1121291, the only thing that needs to change is we have to ask the user for his windows password before showing the password he wants to show

This bug is different from  Bug 902880. In the current bug we dont change how the password are stored, we just use an api to ask him for his windows password: it s a bit cheating so the normal users feel more secure, and he is  indeed more secure against normal people attacks,  however in the a background  : advanced user can still get the passwords.
This is not a solution for all the problems, but its a step in the right path
Flags: needinfo?(rchtara)
Whiteboard: security:passwords → [passwords:management] security:passwords
Duplicate of this bug: 1104740
Priority: -- → P3
Component: Password Manager → about:logins
Product: Toolkit → Firefox

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

Summary: Ask the user for his windows password before showing the passwords in the password manager → Ask the user for their OS account password before showing the passwords in the password manager
Whiteboard: [passwords:management] security:passwords → security:passwords
Duplicate of this bug: 1604185
Duplicate of this bug: 1611982
Assignee: nobody → jaws
Status: NEW → ASSIGNED

The OS auth before setting a Master Password is required since having a Master Password set will supersede the OS authentication.

Attachment #9120927 - Attachment is obsolete: true
Attachment #9124583 - Attachment description: Bug 1194529 - Move the Master Password preference to the Certificate section and require OS auth to set a Master Password. r?MattN! → Bug 1194529 - Require OS auth to set a Master Password. r?MattN!

Adding to the draft 75beta release notes:

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]:
[Suggested wording]: Showing the saved passwords in about:logins on Windows and macOS now requires typing the system account password if no master password is set.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?

(In reply to Julien Cristau [:jcristau] from comment #15)

[Suggested wording]: Showing the saved passwords in about:logins on Windows and macOS now requires typing the system account password if no master password is set.

The user may not have to type anything if they have biometrics setup or they may be able to just enter their Windows Hello PIN instead so maybe we could make this sound more convenient.

Flags: needinfo?(jcristau)

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #16)

(In reply to Julien Cristau [:jcristau] from comment #15)

[Suggested wording]: Showing the saved passwords in about:logins on Windows and macOS now requires typing the system account password if no master password is set.

The user may not have to type anything if they have biometrics setup or they may be able to just enter their Windows Hello PIN instead so maybe we could make this sound more convenient.

Can we use the following wording?
[Suggested wording]: Accessing saved passwords in about:logins on Windows and macOS now requires the user to authenticate with their operating system if no master password is set.

Sure! Draft release note updated.

Flags: needinfo?(jcristau)
Attachment #9129180 - Attachment is obsolete: true
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c2f10d341da8
Move OSKeyStore.jsm to browser/modules since it is no longer used by just Form Autofill. r=MattN
https://hg.mozilla.org/integration/autoland/rev/3242adb0ff8e
Update OSKeyStore pref names now that the module is moved. r=MattN
https://hg.mozilla.org/integration/autoland/rev/55c38d92f65a
Revert to the previous value of the TEST_ONLY_REAUTH pref instead of clearing it after receiving the notification. r=MattN
https://hg.mozilla.org/integration/autoland/rev/5b5cbd52e30f
Ask the user for their OS account password before showing the passwords in the password manager. r=fluent-reviewers,MattN
https://hg.mozilla.org/integration/autoland/rev/7bf0a8463e53
Add a test for the OS auth dialog in about:logins and test that the OS auth dialog doesn't appear when Master Password is set. r=MattN
https://hg.mozilla.org/integration/autoland/rev/e83a89eb5007
Require OS auth to set a Master Password. r=fluent-reviewers,MattN
Priority: P3 → P1
Flags: needinfo?(jaws)
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/456987ad7c9b
Move OSKeyStore.jsm to browser/modules since it is no longer used by just Form Autofill. r=MattN
https://hg.mozilla.org/integration/autoland/rev/da20e2d8584b
Update OSKeyStore pref names now that the module is moved. r=MattN
https://hg.mozilla.org/integration/autoland/rev/586d1c69a0e8
Revert to the previous value of the TEST_ONLY_REAUTH pref instead of clearing it after receiving the notification. r=MattN
https://hg.mozilla.org/integration/autoland/rev/9d8f5af6bf5a
Ask the user for their OS account password before showing the passwords in the password manager. r=fluent-reviewers,MattN
https://hg.mozilla.org/integration/autoland/rev/f630ffb8bc0b
Add a test for the OS auth dialog in about:logins and test that the OS auth dialog doesn't appear when Master Password is set. r=MattN
https://hg.mozilla.org/integration/autoland/rev/6427e12d8147
Require OS auth to set a Master Password. r=fluent-reviewers,MattN
Duplicate of this bug: 1342211
Regressions: 1605494
Depends on: 1622514
Depends on: 1622542
Depends on: 1623277
Depends on: 1623109
Attached image WrongChars.png

Don't know if it is a Firefox bug or a Windows 10 bug, but the Italian version of Windows/Firefox shows strange chars in the authentication window.

(In reply to Filippo from comment #24)

Created attachment 9134338 [details]
WrongChars.png

Don't know if it is a Firefox bug or a Windows 10 bug, but the Italian version of Windows/Firefox shows strange chars in the authentication window.

I have the same issue. Also if the Windows user session doesn't have a password, it's not working...

(In reply to Filippo from comment #24)

Don't know if it is a Firefox bug or a Windows 10 bug, but the Italian version of Windows/Firefox shows strange chars in the authentication window.

@flod, could we be having an issue with the encoding?

(In reply to Antoine Turmel [:GeekShadow] from comment #25)

I have the same issue. Also if the Windows user session doesn't have a password, it's not working...

This was just fixed by bug 1622542.

Flags: needinfo?(francesco.lodolo)

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #26)

(In reply to Filippo from comment #24)

Don't know if it is a Firefox bug or a Windows 10 bug, but the Italian version of Windows/Firefox shows strange chars in the authentication window.

@flod, could we be having an issue with the encoding?

All files are correctly utf-8 encoded. That screenshots shows a shameful typo ("propria", not "proprià"), but "identità" should show up correctly. My assumption would be that there's an issue in the code (i.e. the encoding when you pass this string to the OS)?

Flags: needinfo?(francesco.lodolo)

Short question about the expected behaviour: Is it the expected behaviour that I have to enter the OS passwort for every password I want to show or copy in about:logins? Wouldn't it make sense to remember the authentication after the first password prompt until I close about:logins or for n minutes?

I can file a new Bugzilla ticket for this but maybe the current behaviour is the expected behaviour so I wanted to check that first. Thanks!

(In reply to Sören Hentzschel from comment #28)

Short question about the expected behaviour: Is it the expected behaviour that I have to enter the OS passwort for every password I want to show or copy in about:logins? Wouldn't it make sense to remember the authentication after the first password prompt until I close about:logins or for n minutes?

I can file a new Bugzilla ticket for this but maybe the current behaviour is the expected behaviour so I wanted to check that first. Thanks!

Thanks for your question. This has been fixed in bug 1611914 and uses 5 minutes as the timeout. It should appear in the next Nightly build :)

Depends on: 1623695

(In reply to Filippo from comment #24)

Don't know if it is a Firefox bug or a Windows 10 bug, but the Italian version of Windows/Firefox shows strange chars in the authentication window.

Thanks for your comment. I filed bug 1623695 for this issue and am investigating it now.

There is definitely should be an option in settings that allow to turn this future on/off...

(In reply to Avlasenko Vitaliy from comment #31)

There is definitely should be an option in settings that allow to turn this future on/off...

That would defeat the point of the snooping protection…

Ideally we should fill your saved passwords directly into webpages so you don't need to use about:logins to access them and therefore you wouldn't be annoyed. Bug 1611914 will also help. If filling into webpages doesn't work properly for you then please file bugs.

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #32)

That would defeat the point of the snooping protection…
But that will uncomforable for people who use lockwise often. Let it be On by default, but also let turn it Off. Honestly, for me this is excessive feauture, I just don't need it. Master password (don't use it now) is enough for me If I want to protect my passords. So I still think that there sould be a way to turn this feauture off.

Depends on: 1623745
Depends on: 1624255
Depends on: 1626138

I agree that there should be a disable function in some way. Those people like me that use a mouse, like near their bed or on a couch, and don't have their keyboard readily available. I copy paste website names from my mouse alone into the password search to get my passwords then copy paste that in fields outside of firefox and such. So a disable function isn't without merrit.

Can you at least add the disable function after an initial verified master password sign-in? This way you only need to sign in once and us that just don't care about over protections like this can just ignore it?

We should document this feature including the 5 minute timeout. The documentation should be very clear that this isn't a security feature, it's to make it harder for someone to snoop on your saved logins. The OS auth prompt will be used when a master password isn't enabled.

Summary: Ask the user for their OS account password before showing the passwords in the password manager → Ask the user for their OS account password/biometrics before showing the passwords in the password manager
See Also: → 1626472

What about this method in linux?

Depends on: 1626778

(In reply to Javad ahmadi from comment #36)

What about this method in linux?

See bug 1527745. Last we checked there was no way to show re-authentication UI without locking the users whole Keyring which isn't a great UX.

Duplicate of this bug: 1627493
Depends on: 1628029
Duplicate of this bug: 1628401
Depends on: 1630858
Regressions: 1631749
Depends on: 1631879
Depends on: 1632854
Depends on: 1633090
Depends on: 1636032
Depends on: 1636466
Depends on: 1636312
Depends on: 1636511

I contribute to the Firefox support community and there are a number of users requesting an option to disable this feature. While I understand the argument that it would undermine the entire point of this feature, it does sound like having a disable function would be a useful idea, especially for users that only have a single user on their OS.

It could be a setting accessed from the about:logins page that could be only accessed once the user enters their set Master Password or their OS credentials. That way it would have minimal impact on negating the feature.

(In reply to Wesley Branton from comment #42)

I contribute to the Firefox support community and there are a number of users requesting an option to disable this feature. While I understand the argument that it would undermine the entire point of this feature, it does sound like having a disable function would be a useful idea, especially for users that only have a single user on their OS.

Hello, in case you didn't see bug 1636511 we will disable it for everyone early next week probably. In the meantime people can use signon.management.page.os-auth.enabled in about:config.

It could be a setting accessed from the about:logins page that could be only accessed once the user enters their set Master Password or their OS credentials. That way it would have minimal impact on negating the feature.

Unfortunately it's not that easy or we would have done that. That only protects that specific UI of opting-out but that user preference to not have a prompt has to be stored somewhere (e.g. preferences in about:config) and we can't enforce that a true/false value somehow requires the user to authenticate before changing that storage. I think the way we would have to do this is to not use a boolean (true/false) and instead store an encrypted value using a key stored with the OS account. This is significantly more work and complexity which also requires handling users moving their profile across computers (e.g. networked home folders or moving to a new computer) and handling users denying Firefox access to that key stored with the OS (more so with macOS). It's something we can consider before enabling it by default again but it's not as easy you make it sound.

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #43)

Hello, in case you didn't see bug 1636511 we will disable it for everyone early next week probably. In the meantime people can use signon.management.page.os-auth.enabled in about:config.

Ok, thanks for the information on that.

Unfortunately it's not that easy or we would have done that. That only protects that specific UI of opting-out but that user preference to not have a prompt has to be stored somewhere (e.g. preferences in about:config) and we can't enforce that a true/false value somehow requires the user to authenticate before changing that storage. I think the way we would have to do this is to not use a boolean (true/false) and instead store an encrypted value using a key stored with the OS account. This is significantly more work and complexity which also requires handling users moving their profile across computers (e.g. networked home folders or moving to a new computer) and handling users denying Firefox access to that key stored with the OS (more so with macOS). It's something we can consider before enabling it by default again but it's not as easy you make it sound.

Yeah, I was almost certain it wouldn't be that simple. Hopefully someone is able to figure it out because I do think that this feature is actually very useful, but I can also see why users may want to disable it. Unfortunately, I think the biggest hurdle in the way is the issues syncing passwords with Firefox for Android when using a Master Password. Hopefully that gets patched in the Android redesign though.

Depends on: 1636729
Regressions: 1637421
Depends on: 1638096
Depends on: 1638908
Depends on: 1636700
Depends on: 1641473
Depends on: 1642267
Depends on: 1642402
Depends on: 1650223
Depends on: 1653516
You need to log in before you can comment on or make changes to this bug.