Closed Bug 306730 Opened 19 years ago Closed 7 years ago

Improve the "Please enter the master password for the Software Security Device" string

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: sfraser_bugs, Assigned: MattN, Mentored)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [kerh-coa][qx:link:spec][psm-backlog])

Attachments

(4 files)

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"
Flags: blocking1.8b5?
(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
Flags: blocking1.8b5?
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.
1) There is another bug that asks for the master password dialog to become
visually distinct. It suggests to show an icon in the dialog, to make it hard to
create a simple fake dialog using a JavaScript prompt.


2) I see another issue. The dialog often comes up unexpected, and the user asks

  WHY is it required to enter the password???

IMHO, the context calling the dialog should provide an information string,
explaining what's going on. Like "decrypting an email message", "accessing a
stored password for the website or email server you are about to visit".
(There is a bug on file that has a patch that implements it).


3) What about the following suggestion for a multi-message prompt:

  You are about to [decrypt a message / connect to a protected site you have
visited before and have the site's password remembered / create a new personal
key ].

  [Mozilla/FireFox/Thunderbird] needs to access a protected area on your
computer containing your personal keys and certificates.

  To grant your permission, please enter the master password that protects your
[Software Security Device / SmartCard iButton ].


4) What about rewording [Software Security Device] to [Keyring File].
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.).
Whiteboard: [kerh-coa]
*** 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
Priority: -- → P1
Target Milestone: --- → mozilla1.9alpha
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!
QA Contact: ui
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?
Keywords: uiwanted
oh well, you're right...
Flags: blocking1.9?
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
Flags: blocking1.9? → blocking1.9+
Priority: P1 → P2
I agree that the current text is quite confusing.  I don't know the history of revisions before the current, but whereas users probably can get their head around a master password (particularly those who opted in to having one in the first place) I think "software security device" is pretty opaque.

I also agree that the current prompt is pretty similar-looking to what javascript:prompt(...) gets you, but trying to find a fix for chrome spoofing by content -- while incredibly useful -- might derail what is otherwise an opportunity to fix the wording and improve things incrementally.

I notice too that a significant chunk of the early work in this bug was more concerned with giving embedders control over the interface than about improving the string in the default case.  The original report was about the text change, so I don't feel like going back to that question would hijack the bug, but I do hope that if the embedding issue is still a problem, that it gets its own bug.

With all that being said, let me ask a couple of stupid questions about simple fixes:

 - Can we special case the software token that we build in here, and use a different prompt string in that case, because while hacky, it is an important, dominant use case?
 - Failing that, can we special case the label on the software token when we create it, to something like "Browser's Password Database" or "Security Keychain"?

I agree that explaining the motivation for the dialog would be really nice, but I'm not sure it will lead users to make different decisions, and in edge cases that text could be pretty cryptic too.  If we can improve the 95% case (and the original complaint) with a simple fix, I'm very much for doing so.

Adding dolske to the CC list here too, since he lives password management.
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?
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…
Flags: needinfo?(dolske)
(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.
Flags: needinfo?(dolske)
Mentor: bwinton
Attached patch A one-line patchSplinter Review
So, basically this?
Assignee: nobody → dirkjan
Status: NEW → ASSIGNED
Attachment #8561046 - Flags: review?(bwinton)
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.)
Attachment #8561046 - Flags: review?(bwinton)
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]
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 [1] (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.

[1] 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
See Also: → 499556
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+
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 mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/a230d92e4e94
Do not include the token name in prompts for the internal key slot. r=keeler
https://hg.mozilla.org/mozilla-central/rev/a230d92e4e94
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
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.