Closed Bug 306730 Opened 14 years ago Closed 2 years ago
Improve the "Please enter the master password for the Software Security Device" string
4.23 KB, patch
|Details | Diff | Splinter Review|
9.64 KB, patch
|Details | Diff | Splinter Review|
920 bytes, patch
|Details | Diff | Splinter Review|
59 bytes, text/x-review-board-request
99% of users will have absolutely no clue what this password request: "Please enter the master password for the Software Security Device" means. What is a "Software Security Device" to the average web user? This string needs to be either reworded, or I, as an embedder, need to be able to provide my own dialog for this prompt.
I think all of the security dialogs should be reworked so that we hide most of the information behind an "advanced" button or something.
Speaking as another embedder, I'd prefer a way to provide my own implementation of that dialogue instead of it using the standard nsIPrompt interface, so I can substitute a call to my keyring instead of prompting the user.
(In reply to comment #2) > Speaking as another embedder, I'd prefer a way to provide my own implementation > of that dialogue instead of it using the standard nsIPrompt interface, so I can > substitute a call to my keyring instead of prompting the user. Excellent point; on Mac, we'd like to use keychain for this, so we have the same need.
Wow, this is bad. If it can _completely_ confuse me, what's a normal user going to think when seeing it? This seems broken enough that I'm gonna ask it block 1.5. I don't think a string that bad should be shipped. Also, I'm going to go out on a limb here and suggest the replacement text "Please enter your Firefox master password"
(In reply to comment #4) > Also, I'm going to go out on a limb here and suggest the replacement text > "Please enter your Firefox master password" The "Software Security Device" refers to a specific security module; if you had some kind of hardware key, the dialog might refer to that. So a generic string like "Firefox master password" isn't going to work. I think two things need to happen. First, there are many different password dialogs that Firefox can throw up, and if you are doing something like importing a PKCS file, a couple of these can come up in quick succession (enter password for the file, enter master password). It needs to be _very_ clear which password is being asked for. This can be achieved by both changing the appearance of the dialog for different kinds of passwords (maybe we create a different icon for each, and put that in the dialog), or we try to use a different term than "password" for some applications ("pass phrase" or other). We have to bear in mind that there may be a long period of time between the user creating the master password, and then having to enter it later, which means that they must be able to mentally connect the two occurrances. The second thing that needs to happen is that the user-facing strings, many of which bubble up from NSS, need to be changed to be more easily understood. "Software Security Device" is one of these. NSS should provide a key or enum value which the frontend can use to load an appropriate string, so Firefox could show something like "Please enter the password for Firefox's built-in certificate storage" or something.
Is this anything that regressed since 1.0 or did we ship these dialogs forever?
(In reply to comment #6) > Is this anything that regressed since 1.0 or did we ship these dialogs forever? They have been this way forever.
(In reply to comment #7) > > They have been this way forever. Ah, in that case, removing my blocking request. Sorry :-( I do hope it gets fixed eventually, though
The hard part is not reworking the password dialogs, but understanding exactly what to rework the dialogs to. There are a number of passwords that Firefox can ask for. It can ask for passwords to websites, it can ask for passwords for the cert and key database, it can ask for passwords for your token. The 'master password' is usually the password for the cert and key database. Under the covers it unlocks the cert and key database. You will be asked for this password whenever: 1) you want to import user keys and certs into the database. 2) delete user keys and cert from the database. 3) The first time you access your private key to sign a message, decrypt a mesage, or to authenticate using SSL. ----- 4) When ever you access the Symetric key (SDR key) to decrypt your local web passwords. cases in cased 1-3, if the private key lives in a hardware token (smartcard, usb fob, etc), the password for that token will need to be given. case 4 is the case most users who are confused by the dialog run into. We need some solid UI design which takes in account the following: a) will users be confused if cases 1-3 does not clearly identify the password for the sofware security device? b) will users be confused if the same password is requested under different condition under different name. [That is the user notices that he's prompted for the Software Security Device password when he initially logs into his SSL authenticated web, but not when he's already supplied his 'Firefox master password'... and for that matter how does he know they are identical?] c) will changing the UI which sets the passwords help? (currently Firefox's UI does not identify the master password as the password for the software security device. If that UI would change, would that help). d) how much confusion is caused by the prompt's wording, and how much is simply because the prompt exists. (That is, if we change it to "Please enter the master password for Firefox", does that really help)? e) Would having a 'help' button on the password dialog that explained what the password is and allowed you to reset it (which has the side effect of losing all your encrypted passwords and keys) be useful?
> NSS should provide a key or enum > value which the frontend can use to load an appropriate string, so Firefox could > show something like "Please enter the password for Firefox's built-in > certificate storage" or something. NSS already does. "Software Security Device" is the string PSM chooses for NSS. The NSS default string is "NSS Certificate DB" or "NSS FIPS-140-1 Certificate DB". PSM gets these strings from bundles, so programmatically changing them is not that difficult.
What's needed here is consistency, and distinctiveness. Consistency: every time you ask for a password for a particular purpose, you have to use the same terminology for that password (i.e. don't mix "master password for the Software Security Device" and "Firefox master password"). The same terminology should also be used when the user creates the password in the first place. Any iconography used has to be consistent, and consistently applied, too. Distinctiveness: the user should be able to tell at a glance which password is being asked for. This requires iconography as well as text, and possibly a different dialog layout for web passwords vs. token/security device passwords. For security devices, an iconographic representation of the device (e.g. a security card) would be necessary. The same icons should display in the Security Devices UI in the prefs.
I think there's a third thing needed as well: Clarity (or understandability). The wording and iconography should be understandable by someone who has never seen them, or, as in my case, seen them once and then immediately forgotten about them. I'm going to suggest the following test for this: If my friend, who has never used the master password feature (or any other "security device") is using my computer and gets this dialog, she should understand it. If we can get that along with Simon's two, then it'll be good.
I'm fine to make this dialog embeddable. And if you like the proposal from the previous comment, we'll have to, because the dialog gets more complex. The new interface would receive: - string explaining the action in progress - name of the device or file [smartcard or keyring file] being accessed IMHO we should find a wording / dialog behaviour that is fine with everybody and use it consistenly in all products. Having variations of the dialog in different Mozilla based products will make it even harder for users to understand, when they change the product.
Kai: I agree that the dialog should explain why it's asking for the master password/other input. However, as I read comment 13 I find myself thinking of the "Do you want Firefox to remember this password" dialog. It became worded that way after it was decided that even two lines of text was too much for most users. I propose the following: [Enter your master password/other input action] to have [Firefox/product] automatically [fill in logins/other action]. This would, I think, pass my test in comment 12, and with associated iconry/etc could pass Simon's requirements in comment 11. I'm not a usability expert, and I think we definitely should have one look at this.
(In reply to comment #14) > IMHO we should find a wording / dialog behaviour that is fine with everybody and > use it consistenly in all products. Having variations of the dialog in different > Mozilla based products will make it even harder for users to understand, when > they change the product. This is hard to do well. What if the embedder has UI in a different place, and you want the message to refer to the UI ("Go to the Security Preferences to back up your certificates"). Also the style might differ between platforms (e.g. saying "Firefox blah" might be bad on one platform, saying "you" bad on another). I see the argument about string consistency, but you have to remember that embedders can be a very diverse bunch. (In reply to comment #13) > [Mozilla/FireFox/Thunderbird] needs to access a protected area on your > computer containing your personal keys and certificates. "a protected area" sounds like the military have set up an Area 51 on my hard drive. I think it needs to be "an encrypted file" or "a secure file" or something.
(In reply to comment #9, Bob Relyea wrote:) > The 'master password' is usually the password for the cert and key database. > Under the covers it unlocks the cert and key database. IINM, the password affects only the key DB, not the cert DB. And I believe it's ALWAYS the pw for the key DB, not just "usually". Bob, do you know of any circumstance in which that PW is for anything else? Finally, I think it would be Excellent for the dialog to explain why that password is being requested (e.g. "to obtain your stored password for mail server xxx.yyy.com" or "to obtain the data for filling in this form") but I suspect major rework will be needed to pass that information string to the right place.
I think kaie raises one of the major problems with the password prompt: it can come up almost any time, for some very obscure reasons (turn on fips, and you will get the prompt whenever you try to do any cryptographic operation). Once authenticated, it will no longer prompt except in some very specific conditions (attempts to import or remove user keys, for instance). I can understand exactly what things trigger a prompt, but only because I know when the code absolutely needs the prompt. The current scheme was designed to emulate what very early netscape browsers did -- late prompting of the key DB password under the assumption that the user almost never needed to do it. One application I know of solves this problem by agressively forcing password prompting early (at application startup). In this mode, the user isn't confused as to why the password was asked for, it was tied to a specific event. Removable tokens were prompted for on insertion and removal. The problem with this is mozilla goes to great pains to put of starting security components to improve startup time. This throws all of that work out the window. It also requires users to supply their 'master password' at startup, even if the are never going to user ("I just want to go to google, why do I need to supply the !#@!!@# password"). The real thing here is we need to try different combinations and actually do user studies to see what is most effective. bob
re nelson: You and I know what really happens. For completeness: The password actually unlocks the software security device, which is a PKCS #11 module which controls access to the cert and key database. The password itself is the a PBE which is used to encrypt/decrypt entries in the key database (the cert database is unencrypted). The software security device allows users to read 'public' data (which is certificate and public keys) without unlocking it (that is why you can get a cert view with supplying that password). You cannot 'use' the software security device to do crypto without the password (which is why you need to supply the password to do any SSL operation on a FIPS token). So saying it just 'unlocks' the key database is incorrect as well. This goes to show exactly why the problem about what to present is so hard. In the early days of Netscape, we abstracted the whole thing to talk just about your certificate, so users though that their certificate was the critical element in authentication and anyone getting their certificate could become them. Since most protocols depend on giving up your certificate, this caused more confusion than it solved. As far as passing an appropriate reason, it's not as difficult as it would seem. The password arg (also called wincx or historical reasons) is an argument passed in on several NSS calls (those calls which could possibly involve the password callback). That argument is private between the application and it's password callback function, and does not necessarily need to be a window context... it could contain a structure with has both the window context and the context of the operation ("Reading an email", "decrypting an encrypted password", etc.).
*** Bug 100979 has been marked as a duplicate of this bug. ***
-> "Security: UI" to match original bug and the component description.
Component: Security: PSM → Security: UI
This bug seems to have mostly discussion about the actual UI and its meaning, but I've gone back to my statement in comment 2 about the need to provide an embedding interface, and implemented that. I noticed that nsSDR.cpp uses nsITokenPasswordDialogs to change the password of the software security device, and that interface also has a GetPassword function that we can use to prompt for the password. That solves my embedding problem since I can override nsITokenPasswordDialogs just fine. (This won't work correctly in ff yet due to bug 341418, so I'm not requesting review but comments are of course welcome.)
With regard to "substitute a call to my keyring instead of prompting the user." understand that one of the purposes of this dialog is to give the user a chance to control whether or not he is going to allow his private key to be used for this purpose (whatever it is). We really don't want to take control over the user of the user's private key from the user and give it to the web page designer. I'd like to suggest another dialog improvement. I'd like to see a graphic icon in the dialog, one that represents "the Software Security Device". I'd like to see other password dialogs also show icons representing the thing for which they want a password (e.g. a mail server, a web site, etc.) This might help reduce the frequency with which users type in the password for the wrong server, or type in their master password when the dialog wants a server password.
(In reply to comment #23) > With regard to "substitute a call to my keyring instead of prompting the user." > understand that one of the purposes of this dialog is to give the user a > chance to control whether or not he is going to allow his private key to be > used for this purpose (whatever it is). In my embedding application I'm still going to prompt the user, I just want to prepopulate the password entry with the password retrieved from the keyring, and for this I need to know which password to retrieve, so I need the token name. That's something that's simply impossible while this interface is using nsIPrompt. > We really don't want to take control > over the user of the user's private key from the user and give it to the > web page designer. I don't see what that has to do with the web page designer? If you (firefox?) doesn't want to do that then it's fine, you just don't call keyring/password manager from nsITokenPasswordDialogs::GetPassword (and ff doesn't do that right now), but don't prevent embedders from improving their platform integration!
this is still a common problem, everyday i read of users asking "what is that damn security device? i have not any one!" Is there some possibility to fix this for 1.9?
MaK77, try requesting blocking1.9?
oh well, you're right...
The problem is we don't have anything that proposes an appropriate fix. If this is a priority, maybe can get some UI designer's time. My personal feeling is whatever we do, we need to do some user studies to see what works best. The UI string has been changed several times already and confusion still exists. bob
I'm not sure there's an easy/simple fix for this, at least for 1.9. There's a lot of indirection between the cause-and-effect for the common case (in Firefox) for decrypting stored logins. The extra complication of it being possible to have the prompt invoked from other contexts (certificates?) makes it even more tricky. For the future, I've thought about making the "master password" an explicit, modular part of password manager (so that it would deal with it more directly) instead of relying on the sometimes clunky PKCS#11 token login mechanism. For example: prompt for a passphrase, run it through PKCS#5, and use that as the decryption key. Other modular implementations could obtain it from Keychain or from NSS/PSM as it's done today (eg, for smart cards). That would fix this and some other problems (eg bug 322617), and undoubtedly introduce new ones. :-)
In reply to Justin's Comment 30, the proposal to bypass PKCS#11 would change the security value of the master password from multi-factor authentication to single factor authentication, which would be a real reduction in security. It would also negate FF's claim to be a FIPS-compliant application, because it would be using encryption other than the FIPS-validated PKS#11 module, and thus would make FF ineligible to be used by personnel of many governments. IIRC, the prompt in question is a specific instance of a general prompt which is of the form "enter the password for <PKCS#11 token name>", the instance in which "software security device" is the name someone gave to the virtual token implemented in NSS's PKCS#11 module. IINM, the same prompt is used any time that the user needs to authenticate to any of the user's PKCS#11 tokens, with the name of the token being supplied there. If the user has an Aladdin eToken smart card (as I do), the prompt would at times read "Please enter the master password for the eToken PRO Card 64K." (I see both of those prompts daily.) The prompt is used in other circumstances than for the password manager. But, as presently implemented, the prompt doesn't reveal the purpose of the password request. The prompt sometimes appears when the user doesn't expect it, leaving the user to wonder: if I enter my Master Password now, what will FF do with it? It would an improvement, IMO, if the prompt stated the purpose of the request, e.g. "enter the master password for the password manager", or "enter the master password to retrieve the password for this web page", or even better "enter the master password for the password manager to fetch the password for web site http://<whatever>". To be clear, I am proposing that the generic prompt be increased to have two variables, e.g. "Please enter the master password for <PKCS#11 token name> for <purpose>" I have little doubt that we can improve on the name of the software virtual PKCS#11 token implemented by NSS in FF. "Software Security Device" was chosen to replace an earlier string that was deemed undesirable for reasons I don't now recall exactly. I think we wanted to stop using the words "Data base", and were also avoiding words like PKCS#11, crypto, and token. I also wouldn't recommend attempting to name it the "Password manager" or "password database", because the user's certificates are not part of the password manager, and also, in the context of SeaMonkey, there are other uses, such as email signing and encryption that are neither password based nor web related.
(In reply to comment #31) > ... as presently implemented, the prompt doesn't reveal the purpose of the > password request. The prompt sometimes appears when the user doesn't expect > it, leaving the user to wonder: if I enter my Master Password now, what will > FF do with it? It would an improvement, IMO, if the prompt stated the purpose > of the request, e.g. "enter the master password for the password manager", or > "enter the master password to retrieve the password for this web page", or > even better "enter the master password for the password manager to fetch the > password for web site http://<whatever>". To be clear, I am proposing that > the generic prompt be increased to have two variables, e.g. "Please enter the > master password for <PKCS#11 token name> for <purpose>" Yes, I absolutely agree, and at one point in the past I had attempted to implement that. The patch is in bug 100979, which has been marked as a duplicate of this one... It got never finished, but the code is still there and it should be possible to reuse and update it. Someone would need to do that work...
(In reply to comment #30) > I'm not sure there's an easy/simple fix for this, at least for 1.9. There's a > lot of indirection between the cause-and-effect for the common case (in > Firefox) for decrypting stored logins. The extra complication of it being > possible to have the prompt invoked from other contexts (certificates?) makes > it even more tricky. I don't really understand what you're saying there... Why can't Firefox just prompt for the "Master Password"? That's what it is, isn't it? That's what the user knows it as, having set a "Master Password" in the options.
Flags: tracking1.9+ → wanted-next+
In the spirit of comment #22 , I've attached a patch that should allow extension developers/embedders to replace the password prompt using only js and XUL. Specifically, instead of using nsIPrompt to put up the password prompt, this patch opens a new XUL window. Conveniently, the window I have it open is hidden, and just instantiates nsIPrompt to get the password. So, applying this patch doesn't change the end-user experience at all (they still get the same nsIPrompt dialog box), but should (1) make protoyping a better UI/string easier and (2) help out embedders/extension developers that want to modify this dialog box. I'm still new at this, though, so I don't think the patch is _quite_ right. Specifically: the call to nsIWindowWatcher might need to be proxied to the UI thread instead of running on the current thread? My pattern-matching and googling wasn't good enough to figure out how to do this correctly, though, so I'd appreciate your help. (Incidentally, the actual window-opening code bears a lot of resemblance to nsNSSDialogHelper::openDialog) I don't use nsITokenPasswordDialogs (like comment #22 does), because trunk Firefox3 uses a different set of XUL files for set/change/remove master password, and I felt uncomfortable modifying the existing nsITokenPasswordDialog ones.
Attachment #314766 - Flags: review?(kengert)
Comment on attachment 314766 [details] [diff] [review] Prompt for the master password via a XUL window Directory toolkit is not the right place for UI opened by PSM. There must be an implementation in security/manager/pki I don't understand how your patch would allow an application to override the default implementation. Look how code in security/manager/ssl opens UI that is implemented in security/manager/pki, it uses contract IDs to open such UI. You should do something similar. I don't like your approach of opening a hidden xul window, and to use JS from there. Instead, you should have: - code in security/manager/ssl that calls some interface using a contract ID - the default implementation in security/manager/ssl has c++ code to open the default UI, which can be the current prompt. No need for a XUL window, if all you want is the standard prompt.
Attachment #314766 - Flags: review?(kaie) → review-
This would also cause problems for embedders, who don't have XUL available (whereas today they can provide a nsIPrompt implementation using native interface code in GTK or something).
Assignee: kaie → nobody
Target Milestone: mozilla1.9alpha1 → ---
One thing that is absolutly (security) critical, is to at least add the application name to the dialog; now it is not clear at all at whom you're typing your password. After logging in in the morning, I immediately start firefox and thunderbird. They both ask for a master password using *identical windows* (yes, down to the last pixel!).
If we are at it, there is also no easy way to differentiate from which profile a prompt comes.
This continues to be a problem. Can we just get a better string without making it more complicated?
I have seen it five or six times now, but I still freak all the way out every time I see this dialogue after I first set up password database encryption on a new device. I want to be able to recommend this feature to people, but the UI looks like malware.
Apparently there are layers of things that need fixing - but please first fix the obvious things first, in an obvious way. In FireFox Preferences, I see: [_] Use a master password [ Change Master Password... ] but the dialog box (still, after a DECADE, in FF 30.0) asks "Please enter the master password for the Software Security Device." These two *MUST BE CONSISTENT*. *THIS IS EASY TO FIX*. *PLEASE DO IT*. Moreover, Thunderbird uses *EXACTLY THE SAME DIALOG BOX*. Please *INCLUDE THE APPLICATION NAME* in these dialog boxes! Then, by all means, sort out the complicated stuff and make this even better. But PLEASE PLEASE PLEASE PLEASE fix the simple things first, even if they will need more fixing/tuning in a later stage.
How can this still be an open bug, after ten years of Firefox supposedly focusing on security and the user’s best interests? People are trying to figure out ways of handling online passwords in a secure way, and Firefox is *sooo* close to providing an excellent solution to this, enabling users to use long, random passwords across the web and storing them behind another good password - if it wasn't for the weird wording of this dialog. This strange dialog keeps Firefox preachers like me from recommending the feature to all but the very most tech savvy people. I know that the working order is "if you want it fixed - fix it yourself" but surely this is important enough to be prioritized by Firefox security staff? As suggested in comment #4, make the string "Please enter your Firefox master password". If this string for some reason makes less sense in other contexts where it is shown, surely it is worth the trade-off?
5 years ago
Whiteboard: [kerh-coa] → [kerh-coa][qx]
Do we have a list of triggers and contexts for this dialog? Even if it is used in different situations, there ought to be a less obscure way to phrase the message…
As a note, the string we're talking about changing is located at https://dxr.mozilla.org/mozilla-central/source/security/manager/locales/en-US/chrome/pipnss/pipnss.properties#6
(In reply to Blake Winton (:bwinton) from comment #49) > As a note, the string we're talking about changing is located at > https://dxr.mozilla.org/mozilla-central/source/security/manager/locales/en- > US/chrome/pipnss/pipnss.properties#6 Hm, since note of the strings in this file are understandable for most people, it makes sense to go with something more generic as suggested earlier in this bug (and not differentiate between different cases): "Please enter your Firefox master password" Again, we should ideally also change the icon of that dialog, but that might be material for another bug.
So, basically this?
Assignee: nobody → dirkjan
Status: NEW → ASSIGNED
Comment on attachment 8561046 [details] [diff] [review] A one-line patch No, the string can be used in various programs, not only Firefox. Look up brandShortName and how it is inserted into strings like this The string will then become something like this: CertPassPromptApp=Please enter your $S master password. Notice, the change of the ID, that is needed when a string changes. The you need to also change the ID at all callers of the string. Also, was it decided that the "Software security device" (%S) can be removed? It probably has some value so could be left in the string as additional info.
'Additional info' is an interesting way to describe the three shadiest-looking words I've ever seen legitimate software put in front of me, especially since those three words are never used during the process I went through to set up that password. This isn't some 'oh, advanced users might get some additional context from this' situation; nobody who sees that dialogue for the first time has ever encountered that phrase before. It is of value to nobody.
I might have worded it a little more gently, but I agree with colon's sentiment. :) But I also agree with aceman, in that we'll want to substitute the brandShortName instead of hardcoding "Firefox". The line that does the formatting is https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSCallbacks.cpp#824 There are a few examples of how to do that at https://dxr.mozilla.org/mozilla-central/search?q=brandShortName+ext%3Acpp&case=true&redirect=true (I suspect you could have figured all this out, Dirkjan, but I figured I'ld save you the time. ;) Thanks!
It can be find out directly in Firefox UI where "Software security device" comes from. There are several other "devices" visible. I am not sure if those can also have master passwords or not. A NSS component guru should comment whether it is fine to just drop the info on which "device" is requesting the password. I agree I also never saw anything other than "Software security device" in that dialog. But maybe for users with smart cards or other security "devices" something else is substituted in the dialog title. I assume NSS is a general component of which Firefox maybe only utilizes parts of functionality.
Comment on attachment 8561046 [details] [diff] [review] A one-line patch (As a side note, I'm just a mentor, not a module owner for this code, so you probably want to ask keeler or mcmanus for the actual review.)
Comment on attachment 8561046 [details] [diff] [review] A one-line patch This will break other password prompts. This string isn't just used for the database password. I'm OK with changing the prompt to read "Firefox master password" for the default internal token, but it still needs to include the token name for other tokens. You'll need to pass the actual password prompt code to special case the internal token. bob
Attachment #8561046 - Flags: review-
You'll get that other prompt when you use smart cards mostly. I think better user experience is more important than pretty code, so I don't think we need to have a single string that works both ways. There should be enough information to the password prompt to know if the library is the default Security library and use a hardcoded prompt for it. bob
Whiteboard: [kerh-coa][qx] → [kerh-coa][qx:link:spec]
(In reply to Anton Feenstra from comment #40) > One thing that is absolutly (security) critical, is to at least add the > application name to the dialog; now it is not clear at all at whom you're > typing your password. I fully agree with this (and Anton's later post on it). The first time I saw this popup asking for the password of the security device I had no idea which application was generating it. It looked completely like some kind of malware phishing for a password. Yes it is true the the popup window is bound to the Firefox window, but that's a detail it's hard to recognize and from which to infer the Firefox (or Thunderbird or whatever) application. Security has to be user-comprehensible as well as actually secure. Something like "Please enter the <Firefox> Master Password" makes a lot of sense (if you've set a Master Password, presumably you know what it's for) and seems quick to implement.
Component: Security: UI → Security: PSM
Priority: P2 → P3
Whiteboard: [kerh-coa][qx:link:spec] → [kerh-coa][qx:link:spec][psm-backlog]
Duplicate of this bug: 573700
Dirkjan (:djc, assignee), are you still willing to continue working on this? How can we get some traction on this bug? Can someone summarize what's stopping you from fixing this? I've just added a Master Password to Thunderbird, combined with StartupMaster addon  (for some pseudo-security against unwanted eyes on my mail), which makes the prompt occur *before* showing the main TB window. Iow, I'm now seeing a dubious password prompt without *any* application context whatsoever, because the prompt will float on top of whichever application was last active. As others have said before, this is useless-UI with all the look and feel of malware fishing for a password. I.e., any malware can easily fake the same totally un-contextual dialogue without even bothering about application context. Also, with said addon I now have no way of telling if this is the prompt for TB or FF. Which obviously violates several UX principles (see keywords added), including ux-jargon: > Users should not be required to understand any form of implementation level terminology. > (This principle is a special case of ux-implementation-level) It's hard to understand (to say the least), why Mozilla would seem to take user's security, which is so close to their core mission, so lightly that they wouldn't care to improve this security-relevant dialogue, 12 years after this was filed. *Omg!* Instead of letting this minimalist bug rot and continue exposing users to security risks, we should be busy exploring how the prompt can be supplied with unique features (e.g. a user-defined string token which is under exclusive control of the respective Mozilla applications, or the last date/time this prompt was shown to user, and the application icon!) to make it harder for malware to fake this dialogue.  https://addons.mozilla.org/en-Us/thunderbird/addon/startupmaster/
Sorry for the gross negligence; I'm afraid I won't be able to work on this anytime soon.
Assignee: dirkjan → nobody
Status: ASSIGNED → NEW
This is an initial version without the brand which is less confusing than what we have currently. If that approach is fine then it shouldn't be hard to add the brand in this or another bug depending on when we want to land it.
Comment on attachment 8907303 [details] Bug 306730 - Do not include the token name in prompts for the internal key slot. https://reviewboard.mozilla.org/r/178968/#review184094 Cool - looks good to me.
Attachment #8907303 - Flags: review?(dkeeler) → review+
2 years ago
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
pdol is fine with landing this incremental improvement (without the brand) so I will land it when try is green.
Just some feedback: On the 'smart card' side the prompt it should probably be "Please enter your password for %S" rather than "Please enter your master password for %S". Now that softoken is a special case, we don't need to confuse things for the smart cards (which typically just have passwords, not master passwords). No reason not to land the existing patch since it improves the 99.9% case. bob
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/a230d92e4e94 Do not include the token name in prompts for the internal key slot. r=keeler
Can't believe this is actually fixed! :D Original bug is 16 yrs old: https://bugzilla.mozilla.org/show_bug.cgi?id=100979 So what will the actual string be now in Firefox when a user is prompted for the master password? "Please enter your master password"? If so, that is a huge win for Firefox users’ password security. (Sry for spam.)
There is new code and it seems to have been marked RESOLVED/FIXED. But I really don't think that "Please enter your master password" meets requirements for a fix. A number of the comments above note that identifying which application is raising this prompt is critical. For example, Anton Feenstra said (comment #40) "Please *INCLUDE THE APPLICATION NAME* in these dialog boxes!", and I said basically the same thing (comment #60). Otherwise the prompt really looks like phishing, and which Master Password do I enter? An average user may not notice that the prompt/dialog box may be "bound to" a Firefox window - I certainly didn't at first - and even if it were so bound, why would one assume it's NOT a phishing hack? So please reopen this bug and add the application to the prompt. (I know the same facility is used for at least TBird so the dialog code has to be made context-specific to add the application name.) - Les
I think comment 70 acknowledges that already. But right now the prompt lacks that already *and* is confusing (which was the original bug). The confusing (what is "Software Security Device") is fixed, further work to identify the prompter should go into a follow-up.
Is there a bug for that follow-up?
(In reply to Helder from comment #77) > Is there a bug for that follow-up? Bug 992569 is to add the application name.
You need to log in before you can comment on or make changes to this bug.