Open Bug 101611 Opened 23 years ago Updated 2 years ago

Web sites can easily spoof the Master Password dialog

Categories

(Core :: Security: PSM, defect, P3)

Product:
Core
Component:
Security: PSM
Type:
defect

Tracking

()

Milestone:
mozilla1.9alpha1

People

(Reporter: tpringle, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kerh-coa][psm-backlog])

Attachments

(3 files)

Proof of concept by Kai Engert, displays prompt like Master Password: here for posterity
(deleted), text/html
Details
master password dialog from Aurora build 20110705042005
(deleted), image/png
Details
Master Password Status Icon
(deleted), image/png
Details
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
QA Contact: junruh → bmartin
Version: 2.1 → 2.4
*** Bug 208296 has been marked as a duplicate of this bug. ***
*** Bug 272006 has been marked as a duplicate of this bug. ***
Product: PSM → Core
*** 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. ***
Whiteboard: [kerh-coz]
*** 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
QA Contact: bmartin → ui
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.
Flags: blocking1.9?
-'ing but marking as wanted1.9. Would be nice to have, but should not block the release.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
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.
Johnathan has asked to identify the threat, which is a reasonable request. I don't understand the relevance of the "security through obscurity" remark. Even if the Master Password does become known, the security of the system is not reduced to that. The scheme used in FireFox is essentially a multi-factor system, which requires something you know and something you have. In the case of FF's "Software Security Device", the something-you-have is your key DB. Johnathan's question is, I think, if an attacker can get the user to disclose his Master Password, through what means can the attacker use that to his advantage? I want to divide the answers into two broad categories: a) those in which the attacker has access to the user's system through means other than FF itself, and b) those in which the attacker accesses the user's system through FF itself. The first category includes such things as: - attacker physically takes possession of the user's system - attacker gains physical access to the user's system (keyboard & screen) - attacker gains remote access to the user's system through software other than mozilla, such as (say) VNC, and so has virtual access to the keyboard & screen - attacker has access to the user's files through some network file access protocol, such as (say) Windows' file sharing protocols (SMB) or ftp. FF can't do anything to reduce the user's vulnerability to that class of attacks, once the user's Master Password is disclosed. The second category are those in which the attacker's access to the user's system is through FF itself, e.g. through vulnerabilities in JavaScript or any other browser scripting language freely accessible by web site content. If the attacker who possesses the user's master password can enter it into a master password prompt through some scripting means, then he might be able to login as the user to some other web site, or be able to digitally sign a document on behalf of the user. (In some countries, a digitally signed document saying "I <name> hereby quit deed all my properties and lands to <attacker>" could have financially devastating and legally enforceable effects.) I worry more about the second category that the first because attacks of the second category have much greater ability to scale up to affect massive numbers of users. Not long ago, FF changed the way it handled form tags for file names (the kind used to upload files), so that it was no longer possible for the user to type in the path name of the file to be uploaded (a change I still dislike). This was deemed necessary because it was determined that an attacker's web page can cause a string of the attacker's choosing to be entered into that form, and thereby can fetch any file whose pathname is known. I would like to say that I am confident that no similar weakness exists for the Master Password, but I am not confident of that. So I think this is a concern to take seriously.
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 #22) > 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. (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. As Nelson and Gavin have pointed out - understanding the threat model is not at all the same thing as suggesting the bug shouldn't be fixed, and I'm not sure that trying to shut down that conversation is a really productive way to find a solution here. Solving this, (well... "solving") is complicated. We've got plenty of user data to demonstrate that users will be fooled by so-called picture-in-picture attacks [1]. Making security dialogs look different than content-generated ones is not futile, content can't cross the chrome/content barrier for instance, but there are diminishing returns here. If you make the security dialogs look different, then you count on people noticing when that difference is absent, if you make the content dialogs look different, you count on people not habituating to that. We do some of that - changing site-generated ones to include "The page at http://evil.com says:" but as Jesse points out, that requires people to notice. At least in that case we're using presence, instead of absence. Their password also shows up cleartext in Kai's case, fwiw, though not necessarily in Jesse's CSS case. Yes we could change the icon too, or we could add scarier text that says "You shouldn't disclose secrets here" but that hurts the experience most of the time (since most of these dialogs are legitmate parts of their site's user experience) and I'm not sure it mitigates any risk. As Jesse points out - it's near-trivial to just work around our warnings by reproducing this dialog in content. At that point all we'd be counting on is the hooks into chrome, which is certainly something, but it's a subtle cue, and PSM can't even really count on any particular browser environment. A far preferable way to mitigate this risk would be to make the information useless to steal in the first place - that's generally how you make phishing attacks go away. That's why I wanted to think harder about what attacks we were preventing, because it helps us reason effectively about how to shut down the value of those attacks. So what are we doing here? Is there a visual tweak that we can make to the master password dialog that doesn't run into rapidly diminishing returns, and that doesn't count on users noticing its absence? We already differentiate in the simple case - javascript:prompt("foo") looks different than the real prompt. If there is more we can do, great let's talk about that. Jesse disagreed with Nelson that the problem was fixed, and I agree that it's not "fixed" in that a similar attack could still do a good job of emulating our dialog, but I wonder what we can credibly claim would improve that situation any further? Other than, of course, out of band stuff like phishing filters which shouldn't be forgotten here as part of our defense in depth. I hope this doesn't sound dismissive because it's not written with that sentiment - I sure as hell don't want our users having their passwords stolen. But I also don't want to make this into security theatre. If we write a patch for this bug, I want us to believe it will really change things meaningfully, and I'm not sure what the nature of that patch would be right now. [1] E.g. http://usablesecurity.org/papers/jackson.pdf - Methodology concerns aside, it's hard for me to dispute the conclusion that users are fooled by picture in picture attacks.
> So what are we doing here? Is there a visual tweak that we can make to the > master password dialog that doesn't run into rapidly diminishing returns, and > that doesn't count on users noticing its absence? Yes, there are some. For example: a) Make the Master Password Dialog customizable by the user and force the users to change the default appearance when they set or change the password. b) when writing the password change the appearance of an icon at every key pressure (like Lotus Notes) c) put in the dialog something different for every single installation of the browser, for example the computer name or the user name. Obviously, in this case, all the customization options MUST not be available to the javascript environment, otherwise you can always emulate the appearance and the behaviour of the newly created dialog. I think that password stealing actually *is* dangerous, expecially over a LAN. If I can steal the master password of my desk neighbor, I can "legally" access all his private informations, and usually they includes bank accounts and so on. I know this is not the most common scenario, but security should always be measured in the worst case, not in the best one.
(In reply to comment #28) > I think that password stealing actually *is* dangerous, expecially over a LAN. > If I can steal the master password of my desk neighbor, I can "legally" access > all his private informations, and usually they includes bank accounts and so > on. > > I know this is not the most common scenario, but security should always be > measured in the worst case, not in the best one. Again, I am not saying that there *isn't* a risk, I'm asking how the proposed solutions mitigate that risk. The severity of the risk doesn't change the analysis of whether our approach will do anything to reduce that risk. I would submit to you that we are not "measuring security" in the way you suggest - or at least, we shouldn't be. I think we are all mostly agreeing on whether it's a bad thing for bad people to steal MPs - it is. I want to thank you for putting some ideas forward. Being generative here is the way we'll get somewhere, and I appreciate it. I hope you won't take my replies below as stop-energy - some of them are familiar to me, so I am responding with the background I have to help shed light on them. > a) Make the Master Password Dialog customizable by the user and force the users to change the default appearance when they set or change the password. This is similar, though not identical, to the SiteKey approach used by banks to secure their login pages, where a user-selected image is presented to users. It's not identical, because SiteKey serves not only as a way to authenticate the bank ("They knew that I picked the puppy") but also as a way to authenticate the user ("Which of these 5 puppy pictures did you choose?") In lab studies[1], 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. > b) when writing the password change the appearance of an icon at every key > pressure (like Lotus Notes) Anecdotally, when I worked in usability at IBM, I heard murmurs that users consistently didn't know what those glyphs were for, but I don't have any real data either way. I know they were put in as a direct response to an NSA request, and they tend to know about security things. :) Keep in mind that a site could still spoof this. Imperfectly, sure, but they could make a dialog that seemed pretty responsive and used the same glyph images, just (obviously) not in the correct order. If we had reason to believe that this would affirmatively impact user behaviour though, it's an idea I haven't heard before. > c) put in the dialog something different for every single installation of the > browser, for example the computer name or the user name. Again, this relies on users noticing absence. As I mention though, we do employ the reverse tactic (since it's pretty low hanging fruit) - we mark content-launched javascript:popup()'s pretty clearly as coming from the site. Also as noted though, this wouldn't slow down anything but a very boring attacker. :) [1] http://www.usablesecurity.org/emperor/
(In reply to comment #29) > > c) put in the dialog something different for every single installation of the > > browser, for example the computer name or the user name. > > Again, this relies on users noticing absence. As I mention though, we do > employ the reverse tactic (since it's pretty low hanging fruit) - we mark > content-launched javascript:popup()'s pretty clearly as coming from the site. > Also as noted though, this wouldn't slow down anything but a very boring > attacker. :) 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).
(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[1], 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 [226735], 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.
Assignee: kaie → nobody
Blocks: masterpassword
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?
While the new modal popups can't be spoofed with simple JavaScript alerts, noting prevents a website from using DHTML that can spoof any of the browser dialogs, including replicating the modal effect. 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. Danny's comment about making the whole Firefox window partially transparent would certainly do the trick. At least something in the chrome which is not adjacent / a part of the viewport must be modified in some way. A less graphically intense approach would be to simply grey out some of the chrome in addition to the viewport. As is already recognized, there is a difference between a modal web page dialog, and a modal browser dialog. JavaScript alerts grey out the contents of the rest of the page, but allow navigation between tabs. Whereas, modal browser dialogs like the master password dialog are fully modal. They do not allow any other browser navigation until they are responded to. However, no greying or other visual enhancement occurs to assert the validity nor the importance of the dialog. Adding such a feature would effectively thwart any attempts to spoof secure elements of Firefox.
(In reply to comment #55) > While the new modal popups can't be spoofed with simple JavaScript alerts, > noting prevents a website from using DHTML that can spoof any of the browser > dialogs, including replicating the modal effect. This is bug is for the inverse situation, spoof the master password dialog using JavaScript alerts, the new non native modal dialogs are very different than the master password dialog that is a native dialog window, so I think there is no possibility to fake the master password dialog using a simple alert() call. The other native window that are used for passwords are Proxy/website authentication prompt, but those are user/password combinations so there is a difference (not sure if those differences are enough)
I agree that the JavaScript alert was one important way to prevent spoofing secure dialogs like the Master Password dialog, and one aspect of this bug. The attached proof of concept used this method and has been dealt with. I think that the threat described in the bug remains. Although it is not as urgent or severe, any website could use false imagery and techniques to spoof Firefox modal dialogs. This is similar to the threat posed by websites like the FakeAV scams (pictured): http://community.ca.com/blogs/securityadvisor/Grace/KanyeWest_FakeAV/Fake_AV_2.gif. Sites such as these could still perfectly mimic the Master Password dialog. In my opinion, the effect of emphasizing active content during a modal dialog not only achieves higher security, but has a positive effect on usability. So, I think it is a worthy goal.
(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.
(In reply to comment #60) > 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 agree that transparency isn't the best way to go. A greying effect (in the chrome) like the one currently used for javascript:alert("") is better and would be very noticeable. Other styles of indications in the chrome might be even more secure as you pointed out, but may also be a detriment to the browser's visual style. Another option is for the dialog to overlay the chrome, or to float from on top of the chrome into the center of the screen. But I don't know if that is distinctive enough for user's to be cautious about it's absence.
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.
Attached image Master Password Status Icon (deleted) —
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]
Honestly, it's hard to do a good password prompt. Think UAC since Windows Vista for example, that was something pretty neat at the time and users loved, errr, hated it. You don't have tons of options to do this The Right Way, but you have a few. The password entry prompt, such as any security prompt, should work on a different, homogeneous and secure implementation. As valid options to ask for master passwords, I see: 1. Use a surface considered as privileged, that can not be modified by websites and other untrusted contents. Full screen attacks are to be considered mitigated, so I'd say your only option is to add a layer on Firefox interface on the top: an idea would be a gray background with partial opacity and a blank input.(1) Example: I can't think of any but I'm sure there are. 2. Use a trusted signal or visual that cannot be reproduced by websites, such as a layer encompassing also privileged surface. An example would be a full gray background on the whole Firefox interface, not just the viewport, with partial opacity and a blank input. Example: the aforementioned UAC (if configured at least at level "Notify me only when programs/apps try to make changes to my computer [and dim my desktop]"). 3. Use a Secure key, such as the famous Ctrl+Alt+Suppr required by Windows to login to avoid programs simulating a login screen. The key is only readable by, in this case, the browser, and not from JavaScript. Whatever happens next is under the control of the browser, even if the prompt appears on top of untrusted content. This is designed for use cases where the user trigger the password prompt, not when the password prompt is required due to some interaction, so it would need an additional signal to tell the user to press the secure key (I'm thinking a blinking icon or something). 4. Use a third party input, such as a phone paired with Firefox Sync, that does not have initiated the prompt. On mobile phones, a paired smartwatch? I'm just throwing ideas here. 5. Do not ask for password in the first place. For example, use an OS API on biometrics to store a key. When prompting for a password is unavoidable, my preference clearly goes to option 1 or 2, for obvious UX reasons. When you think of it, as soon as you also figure out a way to clearly specify what is the origin of the password prompt and its destination, you can use the same password prompt framework for everything: master password, HTTP digest, HTTP basic... Preventing the websites to intercept HTTP Basic passwords may sound stupid, but I added it to the list for the sake of consistency between password prompts. For Digest passwords (that should be better differentiated from Basic passwords, but that's another battle), it makes perfect sense to avoid having the website get it. (1) BTW, I don't think a browser-controlled surface that is a layer added on top of the viewport following a user interaction should be considered a privileged surface. An example would be the menu triggered by the hamburger button. This is tricky, but since it opens *mostly* over the viewport you can imagine some tricks by websites to simulate a menu opening. Nope, let's keep the separation between viewport and privileged surface crystal clear.
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

Here is another example of an almost indistinguishable fake prompt. https://fakeauth.com

Imagine my surprise coming to report a security issue in Firefox and finding it already reported 20 years ago, when I was nine years old.

On Linux, the primary password prompt isn't even as system-integrated as the Mac modal; it's just a normal on-top window that doesn't block interaction with the rest of the browser. You'd have to switch tabs or drag it out form over the page to authenticate it, which I do, and which is starting to get on my nerves.

What's more, I suspect a lot of people are using the same primary password and Firefox Accounts password; the rise of Firefox Accounts makes this a more severe issue than it was previously.

Can we please swap the dialog for a doorhanger? Or at least make the dialog pop up outside the bounds of the page?

Also, as the component is now the "primary password", someone should update the issue title, if Bugzilla supports that, so it is easier to find in search.

(In reply to interfect from comment #100)

Yes, please make it a doorhanger. There is actually a seperate bug for this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1149505

This seems to be fixed in Firefox with the "MR1" redesign in Firefox 90. The prompt still overlies the content area and is a simple design that could be replicated easily, but the entire window--including the toolbars and sidebars--is dimmed and non-functional behind the real prompt. A web page could still try to fake the overlay look a single page, and some victims might not notice the difference.

Then again, as a long time Firefox user the example from comment 99 is still pretty convincing even though it looks nothing like the prompt I've been using for the last few months (nightly versions got the change earlier). The fake uses the wrong word ("master" vs "primary") and has a completely different style, and I still might fall for it if I were in a hurry and not thinking. Not sure we can do much better though.

Do we still need this bug as a "PSM" bug, to potentially do something different by default in other applications? I don't think so -- PSM uses the prompt service so Gecko apps have the ability to style it in the most appropriate way for their app. PSM shouldn't second-guess that.

Flags: needinfo?(dkeeler)

Turns out there are two versions of the primary password prompt now. If a tab triggers the prompt (e.g. first password form with a saved login, trying to see your passwords on about:logins) you get the behavior I described, modal to that entire window. If a background process triggers the prompt (the one I see is sync, but maybe there are others) then the primary password prompt is a separate prompt-sized window, with slightly different coloring. Sometimes? I've seen both styles triggered by (I assume) sync.

This latter version is still pretty spoofable. The spoof can't be dragged outside the content area, or let the user switch between it and the tab it's floating on top of, but an unsuspicious user probably wouldn't notice.

Yeah, I don't think this is a PSM bug, unless the issue is that PSM should be using a different API than nsIPrompt.promtPassword.

Flags: needinfo?(dkeeler)

Perhaps I could have a flag to ask for my master password, on startup, before the browser becomes visible? This way I could rest assured that it couldn't be spoofed based on accidental code changes, new CSS features, etc.

There are ways of forcing the master password on startup. One way that's a bit invasive is to set your startup page to an https site and turn on FIPS mode (Preferences->Privacy & Security->Security Devices->Enable FIPS). Firefox will then prompt for your password on startup.

FIPS mode is invasive in that it will restrict your cryptographic operations (usually in a more secure way), which could restrict access to websites that don't meet the FIPS criteria.

Having a startup page that forces some normal need to authenticate that works, but how to do that reliably escapes me currently.

If it is ALWAYS a drop-down-dialog, then maybe it can't be spoofed .
I generally hit the red-button-close-out to the dialog, if the dialog-box, is in the middle of the window .
Pleas ensure, that it is always a drop-down-dialog .

Oh -- BTW, I'm on a "Catalina" Mac Laptop .

(In reply to Clark C. Evans from comment #105)

Perhaps I could have a flag to ask for my master password, on startup, before the browser becomes visible? This way I could rest assured that it couldn't be spoofed based on accidental code changes, new CSS features, etc.

We have already implemented that approach for Thunderbird in bug 1610390
https://hg.mozilla.org/mozilla-central/rev/b4b71625fcfd

Unfortunately that code doesn't work on macOS, after bringing up the prompt early, it somehow causes the main application to no longer function correctly. That's why we disabled that workaround for macOS in bug 1612456.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 14 duplicates, 37 votes and 83 CCs.
:keeler, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: