Always prompt the user before changing a stored password

RESOLVED FIXED in mozilla1.9.1b2

Status

()

Toolkit
Password Manager
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: Dolske, Assigned: Dolske)

Tracking

Trunk
mozilla1.9.1b2
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

11 years ago
Bug 226735 changed the "Save login? Yes/NotNow/Never" modal prompt to a notification bar.

The same thing could be done for the other pwmgr prompts, such as the prompt to confirm a password change.

With this change, we should also consider removing the case where pwmgr will update the password for a stored login without confirmation. It's probably doing this to avoid being annoying, but if there are cases where it might be doing the wrong thing always prompting with a notification bar wouldn't be a burden for the user. This issue was raised at recent pwmgr security/design review.
(Assignee)

Updated

11 years ago
Severity: normal → enhancement

Updated

11 years ago
Depends on: 408797
The auto-saving of changed passwords was probably inherited behavior from the old wallet-based PwMgr. I think the belief was that if the user manually changed the password from what was replayed they must have a very good reason, and the only reason must be that they want to change it.

This bites me all the time on the 'mailman' admin interface where there's no username (there's only one admin) and each mailing list typically has a different admin password (since different groups of people administer different lists). The password manager is completely useless on the site because each time it replays the password for the last list I administered rather than the one I want. What I would _like_ to happen in that case (but maybe it's too hard) is for PwMgr to remember the password for the list I edit 80% of the time and to ignore me (or ask) when I manually change the password 20% of the time.

On the other side of the coin, though, if there's a strong indication of a password-change form (current-PW plus two identical PW) it'd be a real bummer if people lost their new password because they didn't notice the subtle notification bar instead of the current in-your-face prompt. Not that I like modal dialogs, but password changes are rare enough that it may be a warranted case.
Keywords: uiwanted

Comment 2

10 years ago
Now that bug 408797 has landed, do we want a notification bar for other types of password manager prompts as well?
(Assignee)

Comment 3

10 years ago
I don't think any more prompting changes should be made for Firefox 3 at this point (or probably even can, given the string freeze).
(Assignee)

Comment 4

10 years ago
Mutating a bit...

Bug 408797 basically fixed this bug as titled; the only prompt that isn't a notification bar is the rarely-encountered promptToChangePasswordWithUsernames() prompt. We can spin that off, or just fix it along the way.

The remaining interesting idea in this bug is to get rid of the automatic password changing. Or at least reconsider when that can happen. It's nice to try and be clever about changing the password without needlessly prompting the user (especially with an irritating modal dialog), but I've seen a few cases of this biting users when the change was not desired.
(Assignee)

Updated

10 years ago
Severity: enhancement → normal
Keywords: uiwanted
Summary: Use notification bars for the other password manager prompts (eg, changing a password) → Always prompt the user before changing a stored password

Comment 5

10 years ago
Yep, it should prompt the user in a different way (to change it) if a previously saved login name is typed in, but with a different password.  Something along the lines of:

 "Has the password for this login name changed, or did you just accidentally mistype it?"
Choices:
1. It has changed, so change the saved password to this new one.
2. I mistyped it, so leave the saved password alone.
3. I don't want Firefox to remember the password for this login name anymore.
(Assignee)

Updated

10 years ago
Duplicate of this bug: 357551
(Assignee)

Updated

10 years ago
Duplicate of this bug: 433535
Product: Firefox → Toolkit
(Assignee)

Updated

10 years ago
Assignee: nobody → dolske
Target Milestone: --- → mozilla1.9.1
(Assignee)

Comment 8

10 years ago
Created attachment 337374 [details] [diff] [review]
Patch v.1 (WIP)
(Assignee)

Comment 9

10 years ago
Created attachment 340022 [details] [diff] [review]
Patch v.2
Attachment #337374 - Attachment is obsolete: true
Attachment #340022 - Flags: review?(gavin.sharp)
Attachment #340022 - Flags: review?(gavin.sharp) → review+
Comment on attachment 340022 [details] [diff] [review]
Patch v.2

>diff --git a/toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js b/toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js

>+                if (notifyBox)
>+                    this._showChangeLoginNotification(notifyBox,
>+                                                      selectedLogin, newLogin);
>+                else
>+                    this._pwmgr.modifyLogin(selectedLogin, newLogin);

I guess the idea behind not just calling this.promptToChangePassword is that the dialog-after-dialog is annoying, whereas notification-after-dialog isn't? I'm a bit wary of making the behavior diverge here based on the method used to prompt (dialog vs. notification)...

>diff --git a/toolkit/components/passwordmgr/test/test_notifications.html b/toolkit/components/passwordmgr/test/test_notifications.html

>+      case 18:
>+        // Check for change-password bar, u+p login on u+p form.
>+        is(gotUser, "notifyu1", "Checking submitted username");
>+        is(gotPass, "pass2",    "Checking submitted password");
>+        bar = getNotificationBar(notifyBox, "password-change");
>+        ok(bar, "got notification bar");
>+        clickNotificationButton(bar, "Change");
>+
>+        // cleanup
>+        login1.password = "pass2";
>+        pwmgr.removeLogin(login1);

This removeLogin is also verifying that the change worked, right? Behavior in case 20 is also tested by the removeLogin call - is it worth checking the behaviors of case 17 and 19 (don't change and change, respectively)?

The check you added in getNotificationBar presumably tests _removeLoginNotifications. Can we get tests for the HTTP auth change password notification too?
(Assignee)

Comment 11

10 years ago
(In reply to comment #10)

> I guess the idea behind not just calling this.promptToChangePassword is that
> the dialog-after-dialog is annoying, whereas notification-after-dialog isn't?
> I'm a bit wary of making the behavior diverge here based on the method used to
> prompt (dialog vs. notification)...

That's true, although I did it because the user won't know if the login worked until after the request is sent -- but if we prompt we'll block before sending the request.

Hmm, I suppose a better approach (for both cases) would be to monitor the request that's using the new password -- if it's successful just silently change the password (since we know it worked), and if it failed don't do anything. I'm not sure how to do that offhand, though. (Presumably it's just gluing a listener onto something.)

> This removeLogin is also verifying that the change worked, right? Behavior in
> case 20 is also tested by the removeLogin call - is it worth checking the
> behaviors of case 17 and 19 (don't change and change, respectively)?

No, the removeLogin is mainly just keeping things tidy so we don't end up with a pile of logins at the end of the test. But I suppose it would be good to test the actual button-click results... Shouldn't have anything going wrong at that point, but the extra coverage is obviously good. Looks like that's not already tested anywhere. :/

> The check you added in getNotificationBar presumably tests
> _removeLoginNotifications. Can we get tests for the HTTP auth change password
> notification too?

Hmm, I thought I did. But I don't see it in the patch or my tree. I wonder what happened. *sigh*
(In reply to comment #11)
> No, the removeLogin is mainly just keeping things tidy so we don't end up with
> a pile of logins at the end of the test.

Right, I know it wasn't intentional. It does end up testing the result unintentionally, though, right? The removeLogin will fail if the change failed.
(Assignee)

Comment 13

10 years ago
(In reply to comment #12)

> The removeLogin will fail if the change failed.

Right. At least, with storage-mozStorage it does. The legacy module seems to only throw if the specified host doesn't exist.

And, back to the original point:

(In reply to comment #10)

> This removeLogin is also verifying that the change worked, right? Behavior in
> case 20 is also tested by the removeLogin call - is it worth checking the
> behaviors of case 17 and 19 (don't change and change, respectively)?

These cases should already be handled, because the tests after them depend on their side effects. For example, if test 17 somehow did change the login, test 18 would fail because the changed value would be filled in and wouldn't match the value the test expects.
(Assignee)

Comment 14

10 years ago
Created attachment 342676 [details] [diff] [review]
Patch v.3

Updated with HTTP auth prompt tests.
Attachment #340022 - Attachment is obsolete: true
(Assignee)

Comment 15

10 years ago
Pushed changeset 2f36cde1694c.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b2
(Assignee)

Comment 16

10 years ago
Backed out, seems to have caused leaks on OS X and Windows unit test boxes (although not Linux, interestingly...).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

10 years ago
Depends on: 458598
(Assignee)

Comment 17

10 years ago
Created attachment 342834 [details] [diff] [review]
Patch v.4

Filed bug 459620 on the memory leak. I think it's an uncommon situation that the test just happened to exercise (and is actually unrelated to what this bug is fixing), so I've just added a simple workaround in the test.

Pushed changeset 44d774cce259.
Attachment #342676 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Blocks: 458598
No longer depends on: 458598
You need to log in before you can comment on or make changes to this bug.