Open Bug 101611 Opened 23 years ago Updated 1 year ago
Web sites can easily spoof the Master Password dialog
202 bytes, text/html
14.10 KB, image/png
290.36 KB, image/png
It would be helpful for end users if the master password dialog was visually distinct from other password dialogs so that the user is clearly aware of the distinction. Maybe a lock or key graphic in the dialog would be sufficient. Ccing some UE folks to get their thoughts.
I like the idea of a background image supporting the notion that this dialog is special. I am a little nervous about a lock as symbol since this also means SSL connection in another context.
That's an idea.
Priority: -- → P2
Target Milestone: --- → Future
Version: unspecified → 2.1
I like this bug. Let's fix it. A good reason for fixing this bug is the following web site ;-) http://www.kuix.de/misc/test31/ Fixing this bug would make it harder to confuse users, and minimize the likelyhood that they will enter their password into the wrong location.
Assignee: ssaux → kaie
Severity: normal → critical
Priority: P2 → P1
Since as per Kai's example, it is so easy to trick users to convey their master password to outsiders, let's change the target-milestone to 1.5 or anything earlier than the undetermined "Future". Especially now that there so many nice mozilla logos etc. ==> so, maybe not a lock is needed, but the Mozilla Dinosaur with a big key in its hand... see also http://bugzilla.mozilla.org/show_bug.cgi?id=100979
*** Bug 208296 has been marked as a duplicate of this bug. ***
*** Bug 272006 has been marked as a duplicate of this bug. ***
*** Bug 298407 has been marked as a duplicate of this bug. ***
Summary: Make Master Password Dialog Visually Distinct → Prevent web sites from spoofing the Master Password dialog
Summary: Prevent web sites from spoofing the Master Password dialog → Web sites can easily spoof the Master Password dialog
I just felt like adding it just in case... you know, just keep a copy on Mozilla. Not everyone reads comments.
*** Bug 309262 has been marked as a duplicate of this bug. ***
*** Bug 333710 has been marked as a duplicate of this bug. ***
Here's a critical P1 bug with a working proof of concept that was marked "future" 5 years ago by a former PSM software development manager and has been off the radar ever since. The future has arrived.
Target Milestone: Future → ---
Whiteboard: [kerh-coz] → [kerh-coa]
Target Milestone: --- → mozilla1.9alpha
Version: psm2.4 → Trunk
While we're at it, let's try to distinguish master password dialogs from other password dialogs such as thunderbird's email server password dialog. Maybe some large icons would help, a padlock for master, a mailbox for mail servers, etc.
This does not really affect MacOSX versions because the dialog box is attached to the thunderbird window. when prompted and the focus is not in thunderbird window, the icon in dock will bounce.
-'ing but marking as wanted1.9. Would be nice to have, but should not block the release.
Could we find a UI and XUL person to help with this bug? This is really about the presentation of the dialog, only, and does not require any backend work, but would be a big improvement.
I just tried Kai's test case (see comment 3) with a trunk browser and the dialog's title bar makes it pretty clear that this is a spoof, IMO. So, is this bug fixed now?
No. Web pages can still make something that looks like a centered dialog using images and forms and CSS. (And who looks at the title of dialogs bar, anyway?)
Beyond the generic idea that it doesn't seem very nice to steal master passwords, what attack are we preventing here? I'm not being combative, I just don't know -- Remote knowledge of the master password doesn't grant them any particular privilege with the software token, I assume? So are we worried about the more generic password reuse argument - that stealing this password will likely give the attacker their password on other websites?
What about people reusing the local user password in the master password dialog, it is not that uncommon because both are stored on the local trusted computer, Using the same master password on a public website is not recommendable anyways, but what about this local scenario
Right, I think that suggesting there is no reason to be concerned with protecting the Master Password, implicitly the highest profile password, is analogous to saying there is no reason for not simply broadcasting the Master Password to all visited websites in the first place. security through obscurity is worth nothing - so if this is a legitimate concern (which I think it is), it should be dealt with. Another thing - the whole reason the Master Password exists is to protect the user from malicious users that have local access to Firefox, but that's not to say that someone with local access to Firefox wouldn't simply use a website to obtain the Master Password in order to retrieve other passwords. As far as the solution - I think that others who refer to the whole chrome being spoofable are one the right track. I'm not all that familiar with Safari, but it seems to popup all dialogs in a consistent fashion with a particular position and appearance that would probably be a pain or impossible to spoof. I think that's the kind of approach we need here. All Firefox dialogs should have a consistent and readily identifiable appearance which is as difficult to spoof as possible.
My point was not that the question wasn't valid, but simply that data which the user would naturally assume to be secure and private is not. That in itself is a threat which cannot be quantified, but not ignored either. Who knows what a person uses as their password. Maybe it's their pin number or their SSN. Maybe it's their checking account # in the Cayman islands. Perhaps we can place more of this responsibility on the user, but a traditional user would have no reason to expect that their password could be compromised. So, If only to add a new category to the list of possible threats, exposing the Master Password means (by definition) _exposing private data_.
I don't understand the purpose of all this discussion. *Any* kind of information stealing *must* be prevented. That's it.
(In reply to comment #25) > I don't understand the purpose of all this discussion. *Any* kind of > information stealing *must* be prevented. That's it. The purpose of the previous few comments was to try and determine the severity of this bug. No one is saying that we shouldn't fix this bug, but it doesn't hurt to try and determine how it should be prioritized against other existing security issues.
Severity: critical → normal
(In reply to comment #30) > Just a quick thought: One could let the user actively select his username of a > list of maybe 5 names in a combo box. That means that during the setup of a > profile 4 names have to be created randomly. If someone tries to spoof this, he > has to know at first the correct user name and maybe also the 4 false names > (but that depends on the user again, if he would notice a change in those names > or not). That's an interesting idea actually - but it probably is a bit more trouble then some people want to deal with if they are prompted for their MP dialog every time a password dialog is filled in (which I am). I don't think there would be any need for randomness - the remote script/website should never be aware of the users profile name, I don't think. The Master Password could be created on a per-Firefox-profile basis and when prompted for the password, the user could have to select his profile from a drop-down before entering it. The interruption in visual and in function would probably be significant enough to increase the likelihood of a user noticing that the dialog was being spoofed. However, the solution I have always leaned toward was on the order of site-key, or altering all the dialogs such that it looks noticeable, and almost tacky when an attempt to spoof the dialog is made. (In reply to comment #29) > In lab studies, over 90% of users continue to supply credentials on SiteKey > sites when the SiteKey images are altered or removed. This is what I mean by > relying on users noticing absence, you're counting on them to treat things as > more dangerous when a cue is not there. The reason I like SiteKey is because I think it is an idea that has promise, from a UI standpoint. It's an extremely effective security measure when taken advantage of, it's unobtrusive and doesn't require any extra effort from the user, and when users get more concerned about security they will know to look for it.
Users should never be prompted for password asynchronously a dialog box that is presented to accept the password. This is always susceptible to Trojans. Rather, the user should be informed of the need to enter a password, possibly via a dialog box, but preferably some other way (flashing window bar that says "need password to continue"?) and then take appropriate action using the facilities of the application to supply a password. For Firefox, this would having a password entry spot always visible, or a button or menu entry to request a password entry dialog, in the "chrome" (I think it is called) of Firefox. Such a box would be used to respond to the request for password, if and when the user chooses to respond. I guess that solution wouldn't necessarily work for "kiosk" mode, but then again sites accessed via kiosk mode should request passwords ahead of time, via login forms, rather than using the "password protection" feature of the web server to cause an asynchronous request for password.
IMO, a master password should be entered in the URL edit control, with an indication that it is being demanded. If it is possible, the interface element should be one that is not alterable by extensions, etc. An approach like this could also go a long way to dealing with bugs like #348997 since prompting for the master password would have to be serialized.
I think we should try to collect ALL the issues with Master Password dialogs in one place, and try to fix them all in one shot, rather than as a bunch of little hacks. All these issues come to mind: - dialogs are spoofable - multiple concurrent dialogs - dialogs that appear out of the blue and leave the user wondering: why in the world am I being asked for my Master Password now? What even has raised this prompt? - there may be others not coming immediately to mind There are bugs filed on all these things.
Maybe a little bit off topic, but there is another "problem" with password / master password dialogs. Using Firefox and Thunderbird at the same time, sometimes password dialogs from both applications are shown - they are hard to distinguish. Maybe toolkit could be able to make these dialogs different for different apps?
The Master Password prompt has bothered me since it was first added. I was certain it would be changed in FF3, but seeing as it has not, I feel I should comment. I've also raised these issues on the IRC #firefox channel on freenode. Firefox 3 drones on-and-on about unification of dialogs. It's time the Master Password prompt joins this unification. Specifically these points: - There is absolutely no reason the Master Password dialog should be Modal (always-on-top and in-your-face). - The Save Password dialog has been changed in FF3 to Non-Modal , so now is the perfect time to change the Master Password dialog. - Because the Master Password dialog is Modal, it halts all activity (downloading, page rendering) in Firefox until a password is entered. This is especially prevalent when multiple tabs are try to load from a previous session, and become stalled while waiting for the master password (ie, you're AFK). My suggestion is simple. Change the Master Password ModalDialog() to a Toolbar like Find. This way the user can enter their Master Password at their leisure without interrupting their work-flow. It would also be nary impossible to spoof.
There are circumstances where it is logical for the master password dialog to be modal, circumstances where forward progress on some user-initiated activity cannot progress until the MP is entered. It makes sense for the MP to be modal in those circumstances. Only in circumstances where the MP is not truly needed, but rather is optional, because the operation can proceed without it, does it make sense for it to not be modal. I agree that embedding it into a toolbar makes a lot of sense with regard to the issue of spoofing, which is the subject of this bug.
I agree with the toolbar being a good alternative UI. I would go farther and say the redesign should put this into Toolkit where any core code based application using the Master Password function could implement the feature. If I were using this feature, I would like to use the Toolbar Pallet and drag the Password box/bar up to my Menu Bar which would be a good size match. Availability in the pallet could be a conditional based on selection of "Use Master Password" in the User preferences/options UI.
(In reply to comment #38) > I agree with the toolbar being a good alternative UI. I would go farther and > say the redesign should put this into Toolkit where any core code based > application using the Master Password function could implement the feature. > > If I were using this feature, I would like to use the Toolbar Pallet and drag > the Password box/bar up to my Menu Bar which would be a good size match. > Availability in the pallet could be a conditional based on selection of "Use > Master Password" in the User preferences/options UI. > I hope this wouldn't make the Master Password unusable on SeaMonkey (where password UI is moving to the Toolkit backend IIUC, but customizable toolbars are still for a distant future if ever). Adding a few CC to keep this issue in mind if need be.
(In reply to comment #39) > (In reply to comment #38) > > If I were using this feature, I would like to use the Toolbar Pallet and drag > > the Password box/bar up to my Menu Bar which would be a good size match. > > Availability in the pallet could be a conditional based on selection of "Use > > Master Password" in the User preferences/options UI. > > > > I hope this wouldn't make the Master Password unusable on SeaMonkey (where > password UI is moving to the Toolkit backend IIUC, but customizable toolbars > are still for a distant future if ever). > Specifically I would like to see this for Thunderbird where We frequently employ UI designed for Fx with our own Tb flavors added.
(In reply to comment #39) > I hope this wouldn't make the Master Password unusable on SeaMonkey If the possible solution goes the same way as the new save password prompt, i.e. a notification bar prompt, then it flawlessly works with the SeaMonkey Browser. So let's see first what the patch will be. Of course, this does not solve the case for any non-browser software that needs you to enter the master password, like SeaMonkey mail or Thunderbird - so let's see what solution they come up with before we rant about where it may or may not work. ;-)
I'm afraid that the "notification bar" prompt is also easy to spoof, if not easier even.
In reply to comment #41: [...] so let's see what solution they come up with before we rant about where it may or may not work. ;-) I wasn't ranting (in my comment #39) -- just keeping eyes open, and trying to be safe rather than sorry. :-)
In the mail clients, all (or nearly all) master password prompts make sense to be modal. Except for the MP prompts from Password Manager, none of the operations for which the MP is requested can continue in the absence of the MP, AFAIK.
(In reply to comment #41) > (In reply to comment #39) > > I hope this wouldn't make the Master Password unusable on SeaMonkey > > If the possible solution goes the same way as the new save password prompt, > i.e. a notification bar prompt, then it flawlessly works with the SeaMonkey > Browser. So let's see first what the patch will be. > The mention of a notification bar reminded me that Tb currently has a deck, msgNotificationBar, holding three bars, phishing, junk, and remote content. Inclusion of another bar could reuse some existing code and real estate. So if SM is using a similar solution, the two mailnews tools could share and have a common User experience.
I'm afraid I'm not too familiar with every instance where the Master Password is used in Firefox and other Mozilla code. I do know that the _majority_ or most popular use is in filling out saved passwords. I do know that Firefox receives occasional bouts of scrutiny whenever some popular blogger or off-beat news site discovers the "Show Passwords" button under the Security tab, and that most users would benefit from the presence of a Master Password; be they in a multi-person environment or just good security practice. We added the "Show Passwords" button because we don't believe in Security Through Obscurity, but we neglect to provide easy access for users to set a Master Password in the first place. Perhaps the UI change can include Master Password setting/entering within the associated UI that begets saving/entering a Saved Password of any type. Every user would be made aware of the availability of setting a Master Password upon their first, and subsequent, attempts to Save Passwords.
> I do know that the _majority_ or most popular use is in filling out saved > passwords. In ONE of Mozilla's products, the browser, that is true.
Would it be too much to request that a configuration be added to the security tab to force the request for the master password before any tabs start loading? This would be an interim solution (okay, hack) that would help to mitigate the problems associated with this this bug as well as bug #348997.
As of today the master password dialogs appears "on demand", blocking the current action. This approach has been trivial to implement. The idea to decouple the master password prompt from the flow of action (making it modeless) is nice, but it has implications. It will mean, if you start some activity which depends on the MP, the action will have to fail. The modeless dialog will have to obtain knowledge on how to restart the action. In some application contexts it might be really difficult to restart the action, or having had a failure (e.g. to complete a signing request) might one to start over on some multi step web forms. Using an modeless master password dialog while keeping it an ondemand dialog is a real challenge, and I think it's not the scope of this bug - a separate one should be used. On the other hand, this bug 101611 requests something very simple: Improve the visual presentation, so that it can not be confused with JS dialogs.
You have a valid point. It would mean adding some asynchronous code that can callback the desired function. Perhaps some rewrites of various functions that anticipate Master Password use before getting as far as demanding it, so the user can be prompted before even starting the action in question (connecting to mailserver, etc) so connections don't time-out. A related problem I mentioned before, is that while prompting for the Master Password in Firefox during a multi-session reload, all currently-loading tabs will halt downloading and rendering and those pages will time-out after 120 seconds. This sucks if you're loading several tabs and Yahoo Mail happens to finish first. I don't like having to babysit my computer waiting for Firefox to completely load after a reboot.
A factor effecting load up is the sequence tree where any option requiring the Prefs.js has to wait till it has been loaded and it's settings activated. If a potential existed to have a master password related file load earlier, sort of in the manner of a splash screen, perhaps some of the babysitting could be avoided later in the startup.
Re: Comment #49 you are correct about the original request of this bug, but it is clearly obvious that simply changing the appearance of the dialog doesn't eliminate the attack of malware popping up a look-alike dialog... if Mozilla can make a dialog look "this special way" so can hackers... possibly not via JS, if Mozilla does something clever, but clearly they can via a separate program. I consider it useless to fix the reported symptom, and ignore the underlying bug... the first step in fixing a reported problem is to analyze what the problem really is, and then figure out the solution. In this case, the problem is that Mozilla is training users (like Pavlov trained his dogs) to type in Passwords as soon as possible upon presentation of asynchronous dialogs requesting them. Solutions may vary; here are a couple, others are likely possible: * a reserved place for entering passwords that is always visible, but which blinks when a password is needed, and some indication of which password should be entered. * a button or menu entry that can be used to generate today's password dialog on user demand, when some indication is made that a password should be entered (the button could blink, or an alert dialog could be presented -- although it would be annoying to have to dismiss that one separately -- maybe the user entering the password could automatically dismiss it) Without understanding the code, it seems that the modality of the password dialog prompt could be achieved by having a replacement type of modality... the dialog effectively waits for the user to respond to it; the replacement code should simply wait for the user to enter the requested password in a different manner, and then continue when that has happened. Perhaps it is true that some code could/should be restructured (comment #50) but that could be independent of fixing this bug.
I have an idea: make the Firefox window partially transparent when the Master Password dialog box appears.
I believe this bug is now obsolete and therefore FIXED due to the new modal popups?
(In reply to comment #53) > I have an idea: make the Firefox window partially transparent when the Master > Password dialog box appears. Interesting idea, I like it. Could be used for other modal dialogs in the browser as well.
Take a look at Master Password+ https://addons.mozilla.org/af/firefox/addon/master-password/ for some great improvements to the current Master Password implementation... Screenshot of partially transparent window with dialogue box: https://static.addons.mozilla.net/img/uploads/previews/full/53/53662.png
I don't think transparency by itself is a robust solution. Transparency in the chrome may not have a noticeable effect if there is another Firefox window lined up behind, and transparency in the content can be spoofed if the page knows what is behind. I would prefer some distinctive indication in the chrome.
I believe Opera has their credential entry dialogues attached to the urlbar. For Firefox I don't think this would be viable of course, seeing as a lot of work has been done to organise and remove unnecessary notifications, but I agree that transparency wouldn't be the best option (though it is nice eye candy from the Master Password+ addon - hopefully other ideas from this addon can be included in Firefox sooner or later), but some sort of attachment to the chrome seems the only other option... Or change how and when the Master Password box appears and what it visually looks like. I'm not sure if there is plans to combine Firefox Sync and Master Password, but putting some branding/visual appearance to the password entry box help to prevent spoofing.
Here is the current master password dialog in Firefox Aurora (on Linux). Is this still a bug?
(In reply to comment #64) > Here is the current master password dialog in Firefox Aurora (on Linux). Is > this still a bug? Yes. Nothing has changed from the perspective of this bug.
for windows branch... maybe it's good to reproduce Windows UAC behavior? special sound (can we use microsoft sound, stored in system, firefox should not include copyright-protected content), block and dim whole firefox window (not all desktop, like real UAC). and display password dialog over this. i think, it will be very familiar to windows users
Cant' the Save Password doorhanger be reused for this?
I agree with either a doorhanger or bottom bar like Find. There should also be the option to enter your Master Password in the Profile Select dialog.
I agree with either a doorhanger or bottom bar like Find. There should also be the option to enter your Master Password in the Profile Select dialog.
I agree with the value of unifying dialogs, but as has been presented here, I think that some dialogs are too easy to spoof. A find bar would be trivial to emulate, so provides no benefit toward fixing this bug. The save password door hanger does overlap the chrome, but I think the effect is minimally noticeable. CSS effects could replicate the behavior within the viewport (simply moved down a few pixels).
Indeed. If you say both a 'find bar' and a 'door hanger' can be easily spoofed as well, I think this may present an opportunity to take a stronger look at how Master Passwords work in general. I think this could also be coupled with an opportunity to revamp the Profile Creation/Selection process which is presently undervalued and unknown to most users who would indeed use multiple Firefox profiles on a single Desktop profile. The way I see it, a Master Password implies to most users that "Firefox is Password Protected", above and beyond just encrypting the saved passwords database. I would go so far as assert that users believe a Master Password does (or should) encrypt all their bookmarks, browser history, and generally limit access to the Browser to users without that password. To that end, I suggest that the Master Password prompt be presented upon starting Firefox, and be visible before any page rendering and spoofing can take place. This would be a good time to couple Master Password and Profile Selection, and make both features more easily accessible from the Tools menu. (Presently, the only way to create a secondary Profile is to learn command-line switches).
Interesting thoughts. I think that it could be dangerous to make this the only way of utilizing the master password. A prompt upon starting the browser would severely hinder the user experience. Personally, I would want any modifications of this degree to be configurable. I myself have a limited view of what I want Firefox to protect for me, and that is my passwords.
I know this is starting to get a bit off topic, but I have to ask, why would you stop at protecting only your saved passwords? Why not your form-complete history? Existing malware can scrape your credit card info from any number of poorly designed websites you made payments to, because Firefox caches that form data. This seems to be especially true with small municipal utilities; my gas, water and electric companies' payment forms all serve up my credit card number from my previous payment.
I think it is a matter of security vs. convenience, which seems to be a common trade-off for home users. It's why Microsoft had to allow UAC to be disabled completely for people who couldn't bear to be prompted so frequently. One thing that's certain is that elevation should only be performed when necessary. Entering a password once at startup but never again wouldn't provide any more security than I already have on my password-protected computer account.
> "Entering a password once at startup but never again wouldn't provide any more security than I already have on my password-protected computer account." That's how it is already, in practice. You start Firefox, and your previous tabs including Webmail and Facebook load, or you load these immediately, and you are prompted for your Master Password to log in. You enter your password once at startup but never again. One time I had Firefox running for almost 6 months and nearly forgotten my Master Password. The key here is that simply having a Master Password prevents external processes from reading Firefox's user data (saved passwords) because they are encrypted. I propose that encryption extend to other user data as well. I have no problem with user-configurable settings to mandate the Master Password is required once, each time, at startup or on-demand.
(In reply to Raccoon from comment #71) > Indeed. If you say both a 'find bar' and a 'door hanger' can be easily > spoofed as well, I think this may present an opportunity to take a stronger > look at how Master Passwords work in general. In the case of the door hanger there is a visual hint that (at least theoretically) makes it possible to tell apart a spoof from the real thing. > The way I see it, a Master Password implies to most users that "Firefox is > Password Protected", above and beyond just encrypting the saved passwords > database. I would go so far as assert that users believe a Master Password > does (or should) encrypt all their bookmarks, browser history, and generally > limit access to the Browser to users without that password. Same issue with Thunderbird and the mails. But even if these things were encrypted by Firefox somebody might still find remains from these things when paging happens, therefore somebody who wants to be certain should encrypt everything. > This would be a good time to couple Master Password and Profile Selection, AFAIK, the profile selection UI is going to be removed soon. (In reply to inarius from comment #74) > Entering a password once at startup but never again wouldn't > provide any more security than I already have on my password-protected > computer account. Just to get something clear, the master password prompt (at least the first) is not simply a query but the master password is used for encrypting saved passwords. In major operating systems for PCs this is per default not the case, ie. the majority of your personal data is NOT encrypted using your logon password.
The UAC-like feature is not bad IMO, and I'd imagine relatively easy to implement reliably and quickly (possibly even absolutely trivial). This dialog is blocking everything anyway, it might as well have a visual cue which darkens the whole blocked window, including the chrome. The door hanger isn't bad either IMO, but AFAIK it's async. Async might/can work for some cases (e.g. when a site asks for password, which requires the master password for autofill - autofill can happen if/after user enters his master password) but possibly not for others (e.g. when suggesting to store a newly entered password - less trivial as async since the store has to be delayed and doesn't force master password entry).
There is a mockup for a door hanger Master Password Dialog attached to Bug 809682. You might want to check it out.
(In reply to inarius from comment #55) > The only way to truly prevent spoofing is for dialogs to extend from or > otherwise modify the browser chrome which exists outside the viewport. For > example, the Safari dialogs which extend from the browser menu bar. I'm surprised that this took a decade to be explicitly stated, as it seems pretty obvious to me, and is what I came on here to say. I'm also quite shocked that it's been a dozen years since this bug was reported and it is still quite simple for a website to spoof the master password dialogue! I would suggest a door-hanger extending from the consolidated menu in the top-left corner, or the menu bar in any applications where a consolidated menu is not used. Every time FF requests my master password, I move it over the browser chrome to ensure that it is not part of the website below. Of course, the website in question should not be able to acquire my password DB, and my weave credentials are not the same, but I still feel that having the master password prompt appearing over the viewport is an unnecessary vulnerability, and all it would take would be a security hole in Java, Flash, or Silverlight, that allowed access to my files, to expose the contents of my encrypted password DB. A couple of directory lists and access to one file should not be all that a website needs to get the entirety of my login credentials!
This addon offers some kind of workaround: https://addons.mozilla.org/en-US/firefox/addon/startupmaster/ It will ask you for your master password when you start Firefox. At this time, no website is yet open. Firefox will then not ask you again for the master password. So once you see a box requesting for your master password after you started the browser, be careful, it probably is spoofed. But I agree that the problem should finally be solved.
One obvious problem is that we can't use a doorhanger, because it's attached to the address bar and therefore visually and in UX concept attached to the website, while the master password is not website-specific but for the whole browser. We currently don't have a UI concept at all for things like this that are for the whole browser (instance).
What if you attach the doorhanger not to the address bar but to the "Firefox"-button on the top left that opens the menu? This would make it visually clear that it's not website-specific. Another approach would be to use something similar to the Windows UAC prompt. It darkens the whole screen and focuses the user on a new "modal" window in the center. Because websites cannot darken the entire screen/browser (only the website itself can be darkened, not the UI with the address bar etc.), this would allow users to distinguish spoofed windows. On Windows, you could even use a "safe desktop" for the master password. It works like a UAC prompt, but it has the huge advantage that keygrabbers cannot access it (at least not that easily). Keypass optionally does this when you enter the master keyphrase. Problem is that there is no such possibility on other operating systems (or if there is, it would be os-specific for every os). Yet another approach would be to let the user specify some image when specifying the master password. Whenever the master password is prompted, this image is shown. A website spoofing the prompt cannot know which image the user chose. This is similar to yahoo's "personalized login seals". So there are lots of possibilities to solve this. Just go for one.
Bug 809682 has a mockup with using a doorhanger for the master password prompt. This should mitigate the original problem of this bug, at least for prompts on websites. You may either want to mark this bug as a duplicate or depending on bug 809682, whatever you deem appropriate.
Just came across this bug and http://geeksbynature.dk/cers/masterpassword.html. I didn't realize the Master Password problem was this bad, such that any website could spoof it. Users don't understand when and why the dialog comes up, so they have become habituated to just enter their master password to proceed. Hence, it is easy for an attacker to get their hands on this password. The attacker can't do much with it unless they a) have access to the users machine or b) the user reuses the masterpassword at other important sites. Either way, master password needs a makeover.
Component: Security: UI → Security: PSM
Priority: P1 → P3
Whiteboard: [kerh-coa] → [kerh-coa][psm-backlog]
How about using some unique but constant information (like the user's OS username) to generate a background color and/or an identicon? Or perhaps have the user pick an image to use as background the first time the dialog is shown?
What if we put the master password prompt in a doorhanger?
(In reply to Tanvi Vyas [:tanvi] from comment #88) > What if we put the master password prompt in a doorhanger? I agree that a doorhanger is the way to go. I recommended this in this thread back in 2007, not knowing what it was called but referencing the fact that Safari system dialogs used to partially overlap the browser chrome in a way that was difficult to spoof by a client website. I think the addition of a security image would also be an added benefit.
I would also welcome a doorhanger, especially since this would provide a much better UX as the dialog wouldn't need to be blocking the other windows and could be site-specific (only be visible when you actually visit the tab that spawned it). I have my mail pinned in Firefox and every time I open the browser, I use it for a few seconds, and then the prompt from the background tab pops up and steals my focus, and even though I don't want to use any logins at the moment, I have to enter my master password. This change could be part of the better UX in Photon.
Same goes for the HTTP auth dialog tbh, it doesn't make sense for it to be blocking everything else
You need to log in before you can comment on or make changes to this bug.