1342412 - In a FIPS environment, certutil should explain the stricter password requirements

Status: RESOLVED FIXED

(NSS :: Tools, defect)

Description

[Kai Engert (:KaiE:)]

If certutil -N is executed in a FIPS environment,
it should explain the expected password strength requirements.

Today it requests
  "The password should be at least 8 characters long, 
   and should contain at least one non-alphabetic character."
which is insufficient for FIPS mode.

Comment 1

[Daiki Ueno [:ueno]]

Attachment: certutil-fips-pwreq.patch

This patch improves the password prompt by printing the FIPS requirement.

Comment 2

[Daiki Ueno [:ueno]]

Attachment: certutil-fips-pwerr.patch

certutil -N currently doesn't error out when it fails to set password.  This adds some checks around the call to PK11_InitPin and SECU_ChangePW2 to catch the error earlier.

Comment 3

[Kai Engert (:KaiE:)]

Comment on attachment 8902623 [details] [diff] [review]
certutil-fips-pwreq.patch

Do you want to check if FIPS_MIN_PIN could be moved to a public header file, that certutil could include, to avoid copying the definition?

Comment 4

[Kai Engert (:KaiE:)]

(In reply to Kai Engert (:kaie:) from comment #3)
> Do you want to check if FIPS_MIN_PIN could be moved to a public header file,
> that certutil could include, to avoid copying the definition?

Please let me know if you want to try this, or if it's too much hassle and I should go ahead and check it in.
Thanks

Comment 5

[Daiki Ueno [:ueno]]

(In reply to Kai Engert (:kaie:) from comment #4)
> (In reply to Kai Engert (:kaie:) from comment #3)
> > Do you want to check if FIPS_MIN_PIN could be moved to a public header file,
> > that certutil could include, to avoid copying the definition?
> 
> Please let me know if you want to try this, or if it's too much hassle and I
> should go ahead and check it in.

I was thinking about that, but realized that it is not trivial, considering our RHEL packaging and FIPS validation.

Though it's unlikely, the FIPS requirements for passwords may change in the future.  In that case, all three packages we have (nss-util, nss-softokn, nss) must be in sync about the change.  If we determined the requirements at compile time, there could be any inconsistencies, because we may need to keep shipping older nss-softokn with newer nss-util and nss.

So I would rather suggest to have this constant as a private copy, to make it easily adjustable in such situations.

Comment 6

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/projects/nss/rev/07d0f4131459
https://hg.mozilla.org/projects/nss/rev/597c4badcc6c