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

Status: RESOLVED FIXED

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

Description

[Riadh Chtara[:rchtara]]

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

Comment 1

[Bernardo Rittmeyer [:rittme]]

Bug 1121291 is removing the "Show passwords" button, so I think this would be a wontfix.
Or is this a duplicate of Bug 902880?

Comment 2

[Riadh Chtara[: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

Comment 4

[Matthew N. [:MattN]]

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

Comment 6

[Matthew N. [:MattN]]

Attachment: Bug 1194529 - Ask the user for their OS account password before showing the passwords in the password manager

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Move OSKeyStore.jsm to browser/modules since it is no longer used by just Form Autofill. r?MattN

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Update OSKeyStore pref names now that the module is moved. r?MattN

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Ask the user for their OS account password before showing the passwords in the password manager. r?MattN!

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - 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

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Require OS auth to set a Master Password. r?MattN!

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

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Revert to the previous value of the TEST_ONLY_REAUTH pref instead of clearing it after receiving the notification. r?MattN

This was causing subsequent tests to fail when a pref was set via browser.ini.

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1194529 - Require OS auth before allowing deletion of a login. r?MattN

Comment 15

[Julien Cristau [:jcristau]]

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)]:

Comment 16

[Matthew N. [:MattN]]

(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.

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

(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.

Comment 18

[Julien Cristau [:jcristau]]

Sure! Draft release note updated.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
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

Comment 20

[Dorel Luca [:dluca]]

Backed out 8 changesets (bug 1506602, bug 1194529) for Browser-chrome failures in browser/browser_aaa_eventTelemetry_run_first.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=292572332&repo=autoland&lineNumber=7029

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=0848e394516426235b75898a4172bfeefcb59178

Backout:
https://hg.mozilla.org/integration/autoland/rev/884162af76f5225bbf4efe486959d2fa9757bc56

Comment 21

[Pulsebot]

Pushed by [e-mail]:
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

Comment 22

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/456987ad7c9b
https://hg.mozilla.org/mozilla-central/rev/da20e2d8584b
https://hg.mozilla.org/mozilla-central/rev/586d1c69a0e8
https://hg.mozilla.org/mozilla-central/rev/9d8f5af6bf5a
https://hg.mozilla.org/mozilla-central/rev/f630ffb8bc0b
https://hg.mozilla.org/mozilla-central/rev/6427e12d8147

Comment 24

[Filippo]

Attachment: 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.

Comment 25

[Antoine Turmel [:GeekShadow]]

(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...

Comment 26

[Jared Wein [:jaws] (please needinfo? me)]

(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.

Comment 27

[Francesco Lodolo [:flod]]

(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)?

Comment 28

[Sören Hentzschel]

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!

Comment 29

[Jared Wein [:jaws] (please needinfo? me)]

(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 :)

Comment 30

[Jared Wein [:jaws] (please needinfo? me)]

(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.

Comment 31

[Avlasenko Vitaliy]

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

Comment 32

[Matthew N. [:MattN]]

(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.

Comment 33

[Avlasenko Vitaliy]

(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.

Comment 34

[ice2jafar]

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?

Comment 35

[Matthew N. [:MattN]]

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.

Comment 36

[Luker]

What about this method in linux?

Comment 37

[Matthew N. [:MattN]]

(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.

Comment 40

[Parker]

The web restore screen for Code42/Crashplan has a field for searching files you want to restore, however Firefox nightly() is flagging that as a password field. URL for restore screen would be similar to https://www.crashplanpro.com/app/#/console/device/ with a set of numbers after the last slash indicating the device you are restoring for.

HTML for the node reads as follows:

<label class="restore-tree-heading">
				Find files to restore by name or choose from the list:
				<input class="restore-search" type="text" tabindex="2" placeholder="Search all backup sets in CrashPlan PRO Online">
				<img src="/static/widgets/images/cancel.png" class="restore-search-cancel" style="display: none;" width="16" height="16">
				<img src="/static/images/search.png" class="restore-search-submit" width="15" height="15">
			</label>

Comment 41

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Parker from comment #40)

I have filed bug 1631479 for you. In the future, please file a new bug since this issue doesn't appear to be related to the one you commented on. Thanks!

Comment 42

[Wesley Branton]

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.

Comment 43

[Matthew N. [:MattN]]

(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.

Comment 44

[Wesley Branton]

(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.