Closed Bug 571997 Opened 10 years ago Closed 9 years ago
Copy Password doesn't ask for master password while Show Passwords does
We should probably always ask for both or not ask once showing the list. Otherwise users might assume their passwords are somewhat safe if someone coming by needs to enter the master password to show them, but actually copy will get the password.
This is not OS X specific. This also "works" with: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 ( .NET CLR 3.5.30729) and Build identifier: Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100710 Minefield/4.0b2pre
Quoting bsmedberg in bug 600881: "Since you've already entered your master password, I don't think this needs to block." (I concur)
blocking2.0: ? → -
The bug is -about- the 2.0 version so it can't be 'unaffected'. Maybe the older branch was meant. I guess I agree with the non-blocking assessment (see my bug 600881 comment 1 for why the old behavior wasn't as much protection as people think), but the behavior is wrong and inconsistent. A slight UI change could make things better. Copying part of bug 600881 comment 1: We have other bugs on the fact that the sites and user names alone are valuable information. Perhaps we can solve both problems by moving the Master Password requirement from the "Show Passwords" button to opening the "Saved Passwords" dialog at all (whether or not the Master Password had been previously used in that session). Benefits: 1. "Copy Password" is as protected as "Show Passwords" 2. user name and site info is also protected I'll add 3. You won't have the inconsistency of sometimes being asked for the Master Password twice in a row when looking up a password, depending on whether you've previously used the master password in that session.
I took 2 minutes to do this. It's not hard, but as written the experience is a bit sucky. We should probably track if the master password was entered at all in the dialog so that the user isn't continuously prompted. But then again, I'm pretty sure this isn't used often at all so it probably doesn't matter. I've got blockers so if somebody wants to take this and run with it, go for it. I'll come back to it if I find time.
Attachment #482327 - Flags: feedback?(dolske)
I like the way it was set up in 3.6 ; if you want to see a password, enter the master password regardless of you entering it (or not ) earlier. I leave my FF open for days, so if anyone walks up to it - I do NOT want them to be able to see my passwords. but I also like the ability to copy my passwords, so by combining the two - you get an excellent result, you can copy a password ONLY when you are able to see it (requires master password). what do you all think?
(In reply to comment #10) > I leave my FF open for days, so if anyone walks up to it - I do NOT want them to be able to see my passwords. You may want to use https://addons.mozilla.org/en-US/firefox/addon/master-password-timeout/ to discard the authorization manually or after a period of inactivity.
Comment on attachment 482327 [details] [diff] [review] Patch v0.1 (WIP) Yeah, let's do this (didn't look at the details of the patch, though). The part of me that hates to propagate this security obfuscation gives in to the part of me that agrees with making it consistent with how the pwmgr otherwise works.
Attachment #482327 - Flags: feedback?(dolske) → feedback+
zpao / fryn: want to finalize this patch and pop it in my queue for review? :)
With the patch you'd have to enter the Master Password for each password you tried to copy? Presumably most people are only copying one anyway but that's a fairly ugly flow. Why not simply ask for the master password to "unlock" that whole dialog and be done with it? Those who haven't used their master password yet already get a master password prompt when opening the dialog, just make that happen all the time and call it done. That said, I'd much have something rather than nothing while waiting for a mythical better patch to arrive. Dolske: please review.
9 years ago
Whiteboard: [sg:low local password loss] → [sg:low local password loss][inbound]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low local password loss][inbound] → [sg:low local password loss]
Target Milestone: --- → mozilla7
Could you please provide some information regarding how this issue was fixed in the end in order to verify it in QA? Just want to be sure about the expected behavior. Some simple STRs would be very useful.
(In reply to Virgil Dicu from comment #20) > Could you please provide some information regarding how this issue was fixed > in the end in order to verify it in QA? Just want to be sure about the > expected behavior. > > Some simple STRs would be very useful. Enable a master password & open the saved passwords dialog. Right click & "copy password". You should be prompted for your master password.
Thank you for the feedback. Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0 The user is no prompted when attempting to copy the password from within the Saved passwords dialog. The password will not be copied unless the user enters his master password. Setting status to Verified Fixed.
Status: RESOLVED → VERIFIED
Regression in SeaMonkey 2.8. Build identifier: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8 displays the original symptom; Tools|Password Manager|Manage Stored Password - right click on a domain/username select 'Copy Password'. The user is not prompted for the Master password & the password is copied to the clipboard and can be pasted into any application. Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120312 Thunderbird/11.0 and Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0 works as expected (the user is prompted for the Master Password when 'Copy Password' is selected. So this appears to be SeaMonkey specific.
See bug #667327.
You need to log in before you can comment on or make changes to this bug.