458750 - FIPS mode password change failure must clearly report invalid new passwords

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Kai Engert [:KaiE:]]

It is impossible to change the password of an NSS database while running in FIPS mode.

More details and steps-to-reproduce using the NSS command line tools in a follow up comment.

I've been able to reproduce this bug in both NSS 3.12.0 and latest NSS 3.12.x development snapshot.

Comment 1

[Kai Engert [:KaiE:]]

I've recently filed a similar bug 453735, about master password when using the new shared db feature. No idea yet whether they are related.

Comment 2

[Kai Engert [:KaiE:]]

I was able to reproduce this bug using the following procedure:

- build NSS
- terminal, change into a new empty directory
- certutil -d .  -N
  (use the single character "a" as the new password)
- modutil -dbdir . -fips true
- modutil -dbdir . -list
  (this tells me the name of the token is "NSS FIPS 140-2 Certificate DB"
- modutil -dbdir . -changepw "NSS FIPS 140-2 Certificate DB"
  (type "a" for the old password, use "b" for the new password)

=> ERROR: Unable to change password on token "NSS FIPS 140-2 Certificate DB".

Comment 3

[Kai Engert [:KaiE:]]

I am surprised that I can reproduce the same failure using the older NSS 3.11 tools, too!

So, either this is an old bug, or the behavior is by design?

Comment 4

[Kai Engert [:KaiE:]]

Based on the above testcase, I made another test without FIPS mode:

- modutil -dbdir . -fips false
- modutil -dbdir . -list
  (this tells me the name of the token is "NSS Certificate DB"
- modutil -dbdir . -changepw "NSS Certificate DB"

=> Token "NSS Certificate DB" password changed successfully.


When not using FIPS, changing the password works fine.

Comment 5

[Kai Engert [:KaiE:]]

The tools fail internally with "invalid password".

Debugging this tells me, in FIPS mode the new password gets checked to meet certain requirements, see function sftk_newPinCheck in fipstokn.c

I tried password abcDEF78 and it was accepted.

This tells us:
- we do a bad job communicating the FIPS password requirements
- we are inconsequently, because we allow short passwords when enabling FIPS

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I think the bug here is that NSS (and/or PSM) is failing to communicate to
the user the fact that the failure is due to the new password being 
unacceptable.  

This may require changes in softoken or libNSS, and will require changes 
in PSM.

Comment 7

[Wan-Teh Chang]

PSM needs to report the error SEC_ERROR_INVALID_PASSWORD to
the user, with some explanation of possible reasons the
password is considered invalid:
1. it contains invalid characters (CKR_PIN_INVALID)
2. it is too short or too long (CKR_PIN_LEN_RANGE)
3. it is too weak (there is no PKCS #11 error code for this
   condition, so we're using CKR_PIN_LEN_RANGE as an
   approximation)

If we need to differentiate between CKR_PIN_INVALID (1) and
CKR_PIN_LEN_RANGE (2 and 3), we can add a new NSS error code.

Comment 8

[Julien Pierre]

Users within Sun have also run into this problem too after switching to FIPS. I had to go to their desk and tell them to use a stronger password. It was not obvious at all.

This is a usability. I think we should fix this at least at the library level to report a better error, and in our own tools, such as modutil, and certutil -M .

Comment 9

[Wan-Teh Chang]

I proposed a new CKR_PIN_TOO_WEAK error code for PKCS #11 v2.30,
but I'm not sure if it will be accepted.  One person on the cryptoki
mailing list suggested that I add vendor-defined error codes for
vendors interested in FIPS.  Perhaps we'll have to do that.

I also suggest that we consider relaxing our FIPS password rules
to the simplest form allowed by the testing lab.  Our current rules
are very complicated to explain.