Closed Bug 106587 Opened 19 years ago Closed 19 years ago

FIPS enabled mode fails when Master PWD is not set.

Categories

(Core Graveyard :: Security: UI, defect, P1)

1.0 Branch
x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: ssaux, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

One of the requirement in FIPS mode is that the Master PWD be set. Thus in that
mode, when the db needs to be accessed, the user is prompted for the pwd.  If
the pwd is not set, the behavior should be to ask the user to set it.  Instead,
at least on some platform the client hangs.
Priority: -- → P1
Target Milestone: --- → 2.2
CC'ing relyea.

Bob, is this something that must be done within PSM or NSS ?

When there are many codepaths that access the DB, does it make more sense to add
the logic to trigger the "set password request" to NSS?

Should we create a new callback function, similar to PK11_PasswordPrompt, maybe
called PK11_PasswordSet ?
Also the set password functionality need to be able to tell the application
which token needs a password.  This way the PSM set password dialog can preset
the token drop-down list.  See bug 106939.
Please help. I need answers to some questions.


My suggestion to fix this bug:

- If the application is already running, and the user requests to activate FIPS
mode, the application asks the user to set it first. If this fails, FIPS mode is
not activated.


Question 1: Is it ok for FIPS, if the password is the empty string? I ask,
because we currently allow the master password to be set, but empty.


Question 2: Will a newly created NSS database always default to non-FIPS mode?
Or is it possible, that a user start the browser for the first time, and FIPS is
already activated?

If that is possible, then we need to do something when PSM is loaded. It must
check whether FIPS is enabled and no password is set. I suggest, in this case we
require the user to set it during PSM init.

I wonder what we must do, when the user cancels the request to set the password.
Should the application abort? Or should it disable FIPS? Or should it loop
endlessly until the user has successfully set the password?

Thanks!
Status: NEW → ASSIGNED
1) Relyea can correct me, but the password must not be empty in FIPS mode.
2) I think that's a good question. I could see someone want to customize the
browser distribution to make sure that FIPS mode is enabled by default, and then
there would be a need to ensure that the password be set.  It's probably a
thornier problem to solve in that one must detect at db init that fips mode is
set and prompt the user for a db pwd as soon as possible. If that is too hard to
do, we may not allow FIPS to be enabled by default.  Organizations that want
FIPS can enforce FIPS mode by only allowing connections from FIPS enabled clients.

If we decided to set the pwd during init, then it's acceptable in FIPS mode to
loop until the pwd is set.
Yes,

In FIPS mode you need to set the password.
Newly created profiles are currently and have always been non-FIPS by default, a
newly created profile will always be non-FIPS.

If we want to enable FIP's by default as an option, we would have to build a
design to do it. Yes Stephane we would have to detect the lack of DB at
start-up, but we could initialize the DB to a fixed password (other than '0') if
we are starting in FIPs mode. Do you have any requirements to have an enable
FIPs by default option?
At the moment there's no requirement. In fact I don't think that there is a FIPS
preference, so the only way for tools like mission control to create an install
package that would have FIPS enabled by default would be to use secmodutil if
that tools as the ability to toggle fips mode on the software security device.

If secmodutil has that capability, the browser won't support using it to create
such a special install.

Looking at this again, I have another question.

Do we have to care for all tokens, including hardware tokens?

If a user has multiple tokens, and wants to enable FIPS mode, are we required to
iterate over all the tokens and request the user to change a non-empty password?

What will happen if the user has a hardware token, that is currently not plugged
in? He enables FIPS mode and afterwards inserts the token with an empty
password. Will this cause a problem?

Or can we assume that hardware tokens will always have a non-empty password set?
Attached patch Suggested fix (obsolete) — Splinter Review
Supposed we only have to care for the internal token, this patch implements it.


If we need to care for all tokens, the patch must be enhanced, and the check
extended to all available tokens.
FIPs is just the internal token. Other tokens independently decide if they are
FIPs complient or not on their own.

bob
In that case the patch should do what is needed. Javi, can you please review?
nsbeta1
Keywords: nsbeta1
nsbeta1+
Keywords: nsbeta1nsbeta1+
Keywords: nsbeta1+nsbeta1-
Should we relnote this?
Somehow we missed this, although it has a patch already.
I need to test whether my patch still applies, and if it does, will ask for
review again.
The patch still applies.
Comment on attachment 69435 [details] [diff] [review]
Suggested fix

r=javi
Attachment #69435 - Flags: review+
Sean, can you please review the new wording in this small patch?
> +pw_change2empty_in_fips_mode=You are currently in FIPS mode. It is not
allowed to have an empty password in FIPS mode.

Change to "You are currently in FIPS mode. FIPS requires a non-empty Master
Password.

> +fips_nonempty_password_required=FIPS mode requires that you have a password
set for your tokens. Please set the password before trying to enable FIPS mode.

Change to: "FIPS mode requires that you have a Master Password set for each
security device. Please set the password before trying to enable FIPS mode."


Per the discussion re the term "PKCS #11 Module" in bugzilla 96587, the
following changes to existing text should also be made:

> loadPK11TokenDialog=Choose a PKCS#11 device to load (title for open file dialog) 

Change to "Choose a PKCS #11 module to load"


This line (deviceManager.dtd#44) also needs to be changed:

> <!ENTITY loaddevice.title "Load PKCS#11 Device"> (title for dialog that
appears when you click Load)

Change to "Load PKCS #11 Module"
Sean, thanks for your comments.

You had change requests for 4 strings. However, only 2 of the 4 are new strings
from me - only those lines that begin with a +.

For the other changes, you say they are being discussed in bug 96587. If you
think that change is happening in scope of bug 96587, I would prefer to not
include that change here.
Attachment #69435 - Attachment is obsolete: true
Comment on attachment 83056 [details] [diff] [review]
Patch with updated wordings

r=javi on code and r=cotter on new wordings
Attachment #83056 - Flags: review+
Blocks: fips
Keywords: nsbeta1
Keywords: nsbeta1-
Blocks: 150664
Blocks: 152397
Comment on attachment 83056 [details] [diff] [review]
Patch with updated wordings

sr=shaver
Attachment #83056 - Flags: superreview+
fixed on trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified on 8/26 trunk.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.