595469 - Password Manager save prompt should time out after page navigation

Status: UNCONFIRMED

(Firefox :: Security, enhancement)

Description

[mpeve]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/9.10 (karmic) Firefox/3.6.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/9.10 (karmic) Firefox/3.6.8

As in summary. Imagine the following scenario:
1. Alice logs in to a social networking service, etc.
2. Firefox asks whether she wants to remember the password.
3. Alice ignores the question.
4. Alice logs out.
5. Alice leaves the desk being sure that her account is safe, not noticing the question.
6. Mallory comes to the computer.
7. Mallory clicks "Yes, I want firefox to remember the password".
8. Mallory gets access to the account.


Reproducible: Always

Comment 1

[Daniel Veditz [:dveditz]]

If Mallory has unfettered access to Alice's computer then she's got a problem that goes beyond leaving a prompt showing. Alice could lock the computer, could answer the prompt, could turn off the password manager entirely. If Mallory is a dedicated attacker she could install a keylogger with that kind of access and steal all of Alice's passwords.

But there might be a legitimate enhancement request here. Let's assume it's not Alice's computer, it's just one she's borrowing. Let's further assume Alice is not a regular Firefox user so she doesn't understand the prompt. The prompt stays after the initial navigation because there's no point saving the password if it was mistyped, and that way people can see it "worked". But there's really no point leaving it available forever. We'd have to allow for an initial series of redirects (since login pages can go through one or more redirects), but after some period of time (30s? 1 minute?) a page navigation--such as triggered by a logout link--should cancel the prompt. Maybe there should be a timeout even if there isn't a navigation.

An AJAX-heavy site might be able to log people out without navigating but I doubt many do. Navigation is definitely required if the site uses HTTPOnly cookies.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

We should remove the notification on navigation to another page or tab close (with exceptions of immediate page navigation).  I would rather we avoid specific timers at 30s etc, since these feel unpredictable, and don't respond to a user action.

Comment 3

[Danny Moules]

Unfortunately I don't believe that doesn't adequately address the problematic scenario.

Alice doesn't necessarily navigate elsewhere before she leaves a machine open to physical access. It may happen, but it may not. You could just as well attach the event to a key press - or any other event triggered by user interaction that isn't responding to the prompt.

Ergo, I feel a timeout might be more appropriate - it's adequate for cookie session security.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

How long would you want the timeout to be?  Providing the user with the option to change their mind (either if they didn't bother to remember a password, or if they did store it and would now like to remove it) is a very intentional part of the current design.

I don't see how the new interface is worse than the previous notification bars from a security standpoint, since they would also stay around forever unless the user navigated or actively dismissed them (either by selecting remember or closing).

Comment 5

[Justin Dolske [:Dolske]]

(In reply to comment #1)
> But there's really
> no point leaving it available forever. We'd have to allow for an initial series
> of redirects (since login pages can go through one or more redirects), but
> after some period of time (30s? 1 minute?) a page navigation--such as triggered
> by a logout link--should cancel the prompt.

Err, it should already work this way. The notification bar will ignore location changes for 20 seconds, after which any location change will remove it.

FF4 doorhangers work basically the same way, bug 595175 is tweaking them to make this problem even less likely.